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ABSTRACT 


In  the  Global  War  on  Terrorism  and  future  irregular  battlefields,  the  Marine  Corps 
will  not  only  fight  in  large-seale  eonventional  war  against  sizable  military  forees  but  it 
will  also  engage  adversaries  that  utilize  smaller  sized  units  dispersed  asymmetrieally  over 
vast  geographieal  loeations.  To  address  this  emerging  threat,  the  Marine  Corps  is 
developing  the  Enhaneed  Company  (EC)  coneept,  with  the  aim  of  providing  the  eompany 
eommander  with  the  tools  neeessary  to  make  isolated  deeisions  in  an  inereasingly 
eomplex  battlefield.  In  order  to  make  timely,  independent  deeisions  and  maintain 
information  superiority  these  widely  dispersed  units  will  require  organie  aeeess  to 
services  normally  provided  by  higher  headquarters.  The  Marine  Corps  Warfighting 
Eaboratory  is  working  to  enhance  the  decision-making  capabilities  of  the  infantry 
company  through  the  development  of  the  Company  Eevel  Intelligence  Center  (CEIC)  and 
the  Company  Eevel  Operations  Center  (CEOC). 

Current  Marine  Corps  communications  capabilities  cannot  meet  the  data  demands 
of  widely  dispersed  lower  echelon  units.  The  communications  equipment  organic  to 
these  units  is  mostly  Eine  of  Sight  (EOS)  technology.  These  systems  limit  the 
geographic  dispersion  of  the  units  and  are  limited  in  data  throughput  capability.  To  allow 
for  wider  dispersion  on  the  battlefield  while  providing  the  connectivity  required  for 
isolated  decision  making,  these  units  require  communications  assets  that  are  capable  of 
operating  Beyond  the  Eine  of  Sight  (BEOS)  such  as  Satellite  Communications 
(SATCOM)  equipment. 

This  thesis  will  seek  to  analyze  the  use  of  SATCOM  in  support  of  the  Enhanced 
Company  Concept  in  a  EOB  environment.  Using  a  Eimited  Objective  Experiment,  the 
authors  will  test  if  SATCOM  technology  is  sufficient  to  support  Information  Exchange 
Requirements  (lERs)  developed  in  the  laboratory  and  validated  with  experience.  Based 
on  the  outcome  of  the  experiments  the  thesis  will  provide  recommendations  regarding  the 
use  of  such  technology. 
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I.  INTRODUCTION 


A.  BACKGROUND 

Traditionally,  the  Marine  Corps  brings  Defense  Information  Systems  Network 
(DISN)  services  into  a  theater  via  satellite  terminals  located  at  Marine  Expeditionary 
Force  (MEF)  and  Major  Subordinate  Command  (MSC)  headquarters.  Various  terrestrial 
based  transmission  terminals  then  distribute  these  services  to  the  subordinate  Marine 
forces  in  the  Area  of  Responsibility  (AOR).  Eower  echelon  units  tend  to  use  low 
bandwidth  terrestrial  systems  for  reach  back  to  higher  headquarters.  Since  the  Gulf  War, 
bandwidth  requirements  have  grown  exponentially  at  all  levels  of  organization,  including 
at  lower  echelon  units  such  as  infantry  battalions  and  companies;  the  Defense 
Information  Systems  Agency  (DISA)  claims  that  at  the  peak  of  Operation  Iraqi  Freedom 
“3  Gbps  of  satellite  bandwidth  was  being  provided  to  the  theater  ...  30  times  the 
bandwidth  made  available  during  [Desert  Storm]. Current  urban  and  asymmetric 
operations  in  Iraq  and  Afghanistan  have  served  to  further  increase  the  demand  for 
bandwidth.  In  order  to  meet  this  increase  in  demand,  the  Marines  have  distributed 
terminals  designed  to  handle  large  traffic  loads  as  well  as  satellite  communications 
services,  typically  organic  equipment  at  the  regiment  or  higher  echelons,  as  far  down  as 
battalion-sized  units.  Marine  Corps  units  identifying  a  capability  gap  in  communications 
at  the  lower  echelons  have  submitted  numerous  Urgent  Universal  Needs  Statements 
(UUNSs)  to  expedite  a  solution  to  the  problem.  Efforts  are  currently  underway  at 
Headquarters  Marine  Corps  (HQMC),  Marine  Corps  Combat  Development  Command 
(MCCDC),  and  Marine  Corps  Systems  Command  (MCSC)  to  research  and  procure 
solutions  to  meet  the  bandwidth  shortfall  for  battalion-sized  units  and  below  operating 
using  current  tactics,  techniques  and  procedures. 

Since  1963,  when  MCO  3120.3,  formalized  the  Marine  Air-Ground  Task  Force 
(MAGTF)  the  Corps  has  structured  its  forces  using  a  scalable  and  balanced  air-ground. 


1  Leland  Joe  and  Isaac  Porche  III,  Future  Army  Bandwidth  and  Capabilities  (Santa  Monica,  CA:  Rand 
Corporation,  2004). 
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combined  arms  task  organization .2  This  modular  breakdown  into  ground,  air,  and 
support  elements  has  provided  great  utility  in  organizing  and  deploying  appropriately 
sized  forees  for  eonventional  conflicts  throughout  history.  Based  on  lessons  learned  from 
past  and  eurrent  conflicts  and  a  forecast  increase  in  the  number  of  future  asymmetric 
battlefields,  the  Marine  Corps  is  developing  eoneepts  to  fight  an  elusive  adversary  who 
utilizes  small,  vastly  distributed  units  to  engage  in  loealized  yet  very  violent  actions  and 
who  makes  every  attempt  to  avoid  a  eonventional  massed  force  on  foree  battle.  The 
Marine  Corps  deseribes  these  types  of  threats  as  “hybrid  challenges”^;  challenges  that 
will  require  new  ways  of  deploying  and  better  trained  and  equipped  small  unit  leaders. 
As  part  of  the  effort  to  expand  abilities  to  operate  in  a  more  dispersed  environment  the 
Marine  Corps  is  developing  a  concept  labeled  Enhanced  Companies  (EC).  This  new 
concept  focuses  on  company  size  and  below  units  dispersed  in  urban  terrain  or  at  sueh 
distances  that  limit  conventional  support  capability  of  higher  or  adjaeent  units.  These 
units  will  rely,  more  than  ever,  on  the  spirit  of  commander’s  intent  and  inereased 
autonomous  deeision  support  eapability  to  execute  key,  isolated  actions  that  may  have 
strategic  impact.  To  make  informed  and  timely  decisions,  these  dispersed  forees  will 
require  the  capability  to  organically  gather  and  proeess  information  typically  passed  from 
higher.  These  units  will  not  be  able  to  eount  on  the  already  overtaxed,  smaller 
bandwidth,  and  distanee/terrain  limited  information  exehange  teehnologies  that  exist  on 
today’s  battlefield  to  provide  that  data. 

Speeial-operations  Forees  (SOF)  unit  deployments  are  autonomous  in  nature  and 
are  inherently  able  to  respond  to  both  symmetrie  and  asymmetrie  threats.  Most  SOF 
units  deploy  at  great  distanees  from  adjacent  and  higher  units.  Those  units  are  often 
called  “disadvantaged  users”  in  part  due  to  the  complex  terrain  they  deploy  to,  their 
requirement  for  mobility  as  well  as  their  limited  capability  to  haul  or  power  large  pieces 
of  communieations  equipment.  However,  SOF  units  are  still  able  to  execute  their 
mission  effeetively  beeause  they  are  equipped  with  technology  that  adequately  supports 

2  Edwin  H.  Simmons.  The  United  States  Marines:  A  History,  Fourth  Edition  (Annapolis,  Maryland: 
Naval  Institute  Press,  2003). 

^USMC,  USMC  Vision  &  Strategy  2025,  http://www.marines.mil/units/ 
hqmc/emc/Documents/MCVS2025%2030%20June.pdf  (accessed  17  September  2008). 
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their  information  exchange  requirements.  SOF  and  dispersed  USMC  units  will  never 
execute  the  same  mission  set,  however,  the  manner  in  which  each  type  of  unit  deploys  to 
execute  its  particular  mission  and  the  inherent  communications  requirements  an 
Enhanced  Company  and  its  platoons  will  encounter  are  comparable.  Both  types  of  units 
may  be  operated  beyond  the  range  of  normally  deployed  equipment  or  in  environments 
where  that  equipment  may  not  be  effective  and  therefore  must  substitute  alternate 
technology  for  traditional  methods  of  communication.  SOF  has  successfully  translated 
this  dispersed  type  deployment  directly  into  requirements  documents  to  procure 
SATCOM  equipment  that  provides  the  necessary  links  and  bandwidths.  The  success 
SOF  have  enjoyed  as  a  “disadvantaged  user”  may  serve  as  a  model  for  capabilities  in 
support  of  Enhanced  Companies,  if  not  an  initial  vector  for  Marine  Corps  planners. 

This  thesis  will  analyze  the  utility  of  satellite  communications  in  support  of  the 
Enhanced  Company  concept  by  validating  forecast  information  exchange  requirements 
for  a  dispersed  Marine  infantry  company  and  then  conducting  a  Eimited  Objective 
Experiment  (EOE)  using  SATCOM  technology  to  measure  the  effectiveness  with  which 
the  technology  meets  the  validated  Information  Exchange  Requirements  (lERs).  It  will 
attempt  to  determine  the  best  location  for  satellite  terminals  within  the  MAGTF  structure 
at  units  higher,  lower  and  adjacent  to  the  infantry  company.  The  thesis  will  also  suggest 
which  capabilities  these  terminals  should  have  in  order  to  meet  the  lERs  of  these  units 
based  on  these  experiments. 

B.  OBJECTIVES 

The  primary  objective  of  this  research  is  to  determine  if  the  use  of  SATCOM  is  a 
viable  solution  as  an  information  exchange  technology  for  use  in  the  USMC  Enhanced 
Company  concept  of  deployment. 

A  secondary  objective  includes  the  validation  of  proposed  USMC  EC  lERs 
through  interviews  with  USMC  infantry  units  with  recent  combat  deployment  experience 
in  order  to  help  determine  which  lERs  and  decision-making  applications  the  dispersed 
unit  will  actually  use.  This  objective  helps  lead  the  way  towards  establishing  Standard 
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Operating  Procedures  (SOPs)  and  Tactics,  Techniques  and  Procedures  (TTPs)  that  future 
communication  network  architects  can  use  to  define  capability  sets  for  technology  to 
meet  those  requirements. 

The  subject  of  this  thesis  is  extremely  narrow;  as  compared  to  the  intricacies 
involved  in  developing  an  entire  architecture  that  supports  the  EC  concept.  However, 
this  work  will  not  only  provide  a  possible  answer  for  future  communication  architects  but 
will  also  serve  as  a  starting  point  for  developing  joint  information  exchange  technologies 
that  will  enable  future  network-centric  warfare  concepts. 

C.  RESEARCH  QUESTIONS 

The  primary  research  question  of  this  thesis  seeks  to  determine  if  the  lERs 
developed  by  the  Naval  Research  Eaboratory  for  the  Marine  Corps  Warfighting 
Eaboratory  are  valid  and  if  so,  the  authors  will  seek  to  determine  whether  a  particular 
SATCOM  technology  is  satisfactory  for  information  exchange  by  an  Enhanced 
Company.  Given  a  list  of  requirements  and  technologies,  the  authors  will  provide  a 
recommendation  as  to  the  appropriate  echelon  in  the  Ground  Combat  Element  (GCE)  of 
the  MAGTE  for  deployment  of  those  technologies. 

D.  SCOPE,  LIMITATIONS,  AND  ASSUMPTIONS 

The  scope  of  this  thesis  will  include: 

The  analysis  of  information  exchange  requirements  associated  with  the  Marine 
Corps  Enhanced  Company  to  include  those  exchange  requirements  essential  for 
Intelligence,  Maneuver,  Eogistics,  Command  and  Control  (C2),  and  Eire  Support. 

The  analysis  of  a  current  SATCOM  technology  to  determine  if  it  can  support  the 
information  exchange  requirements  mentioned  above. 

Eield  experiments  at  the  Marine  Corps  Tactical  Systems  Support  Activity 
(MCTSSA),  located  at  Camp  Pendleton,  California. 

Eace  to  face  interviews  conducted  with  a  combat  experienced  infantry  battalion  / 
company  currently  undergoing  pre-deployment  training. 
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E,  METHODOLOGY 

In  July  of  2006,  the  Warfighter  Human  Systems  Integration  Laboratory  at  the 
U.S.  Naval  Researeh  Laboratory  (NRL)  in  Washington  D.C.  provided  an  assessment  to 
the  Marine  Corps  Warfighting  Laboratory  (MCWL)  regarding  a  proposed  optimal  mix  of 
devices  for  infantry  companies  and  below  operating  in  a  Distributed  Operations  mode.^ 
As  part  of  the  assessment,  the  NRL  developed  an  information  exchange  list  for  each 
included  node.  The  main  objective  of  this  thesis  is  to  validate  the  list  provided  in  the 
assessment  by  interviewing  Communications,  Intelligence  and  Operations  Officers  from 
Marine  infantry  units  that  have  deployed  in  support  of  current  contingencies  around  the 
world.  The  experiences  of  units  that  have  deployed  in  real-world  environments  and  in  a 
manner  similar  to  those  conceptualized  by  the  Marine  Corps  Tactics  and  Operations 
Group  (MCTOG)  for  the  Enhanced  Company  will  provide  a  check  to  the  laboratory 
developed  lERs  and  perhaps  serve  as  a  basis  for  doctrinal  information  exchange 
requirements  for  EC  deployments. 

The  authors  will  conduct  field  experimentation  using  a  single  current  commercial 
technology  with  metrics  designed  to  evaluate  the  utility  of  SATCOM  to  meet  information 
exchange  requirements  in  an  Enhanced  Company  environment.  Equipment  performance 
will  be  measured  to  determine  if  that  particular  technology  will  have  adequate  bandwidth, 
be  useable  by  those  that  will  be  utilizing  the  technology  to  communicate,  and  will  meet 
the  portability  requirements  consistent  with  widely  dispersed  and  mobile  units. 

F.  ORGANIZATION  OF  THESIS 

This  paper  is  divided  into  fivechapters  as  follows: 

Chapter  I  consists  of  the  Introduction,  which  provides  a  general  overview  of  the 
background,  purpose  and  methodologies  associated  with  this  research. 

Chapter  II  will  cover  the  currently  published  EC  lERs,  according  to  MCWL,  and 
will  vet  that  list  by  using  input  garnered  from  interviews  with  combat  unit  leadership. 


Coyne,  et  al.,  Final  Report:  Company  and  Below  Command  and  Control  Information  Exchange 
Study  (Washington  D.C.:  Naval  Research  Laboratory,  2006). 
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Chapter  III  contains  information  regarding  the  Limited  Objective  Experiments 
conducted  in  support  of  the  thesis. 

Chapter  IV  consists  of  an  analysis  of  the  data  generated  in  the  experiment 
outlined  in  Chapter  III  as  well  as  the  utility  of  that  experiment. 

Chapter  V  will  provide  conclusions  regarding  the  findings  of  this  thesis.  It  will 
also  provide  recommendations  as  to  the  feasibility  of  using  SATCOM  in  the  Enhanced 
Company  Eevel  Operations  Center  as  well  as  recommendations  regarding  for  further 
research  and  actions  that  will  further  support  the  objectives  of  this  thesis. 
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II.  ANALYSIS  OF  INFORMATION  EXCHANGE 
REQUIREMENTS 


A,  OVERVIEW  OF  INFORMATION  EXCHANGE  REQUIREMENTS 

The  following  sections  explain  the  method  used  to  generate  a  list  lERs  in  support 
of  the  Limited  Objective  Experiment  explained  later  in  the  thesis. 

1.  Background  of  Naval  Research  Laboratory  Report  for  MCWL 

Experiment 

a.  Purpose  of  Report 

In  2006,  the  MCWL  Technology  Division  tasked  the  Human-Systems 
Integration  (HSI)  Laboratory,  part  of  the  NRL,  with  providing  a  human  factors-based 
assessment  of  the  optimal  mix  of  communications  modalities  and  technology  at  each 
communication  node  (point  where  information  flows  into  and  out  of)®.  The  goal  of  the 
MCWL  study  was  to  identify  the  optimal  set  of  communication  modalities  and  gear  for 
Distributed  Operations  (DO)  equipped  units.  When  first  developed,  the  DO  concept  of 
deployment  sought  to  permit  small  units  to  operate  at  distances  beyond  support  from 
adjacent  and  higher  command  elements.  In  this  regard,  MCWL  identified  the  primary 
technical  limitation  preventing  traditionally  deployed  Marine  units  from  adopting  the  DO 
mode  is  the  range  of  their  communications  gear  and  the  increase  in  communications 
burden  that  DO  places  on  the  small  unit  leaders.  The  Distributed  Operations  moniker 
used  for  the  concepts  being  researched  in  2006  has  recently  given  way  to  similar  concepts 
with  different  names. 

The  final  report  includes  a  DO  communications  task  analysis,  the 
information  exchange  list  per  node  and  the  list  of  modes  per  exchange.  Lor  the  purposes 
of  this  thesis,  the  authors  will  focus  on  the  list  of  information  exchanges 


®  Coyne,  et  al.,  Final  Report:  Company  and  Below  Command  and  Control  Information  Exchange 
Study  (Washington  D.C.:  Naval  Research  Laboratory,  2006). 
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where  the  company  is  a  node  and  use  that  list  as  an  experimental  baseline  for  lERs  for  an 
Enhanced  Company,  operating  in  a  Eorward  Operating  Base  (EOB)  environment. 

The  content  of  the  information  exchange  list  and  task  analysis  detail  the 
common  or  significant  communications  likely  to  occur  within  an  infantry  company.  The 
specific  chains  of  communication  detailed  in  this  list  are  based  upon  an  understanding  of 
the  likely  concept  of  operations  (CONOPS)  for  a  company,  or  elements  of  a  company 
operation  in  a  DO  mode,  acquired  through  discussions  and  exchanges  with  other  MCWL 
staff  who  were  directly  responsible  for  the  experimentation  and  development  of  the  DO 
concept.®  Although  not  specifically  developed  as  a  comprehensive  list  for  an  Enhanced 
Company  in  a  EOB  environment  this  list  is  adequate  as  a  starting  point  for  developing  a 
list  of  lERs.  However,  based  on  the  fact  that  the  list  was  developed  in  a  laboratory 
environment,  the  lERs  included  need  to  be  validated  with  real  world  experience  to  define 
what  capabilities  an  Enhanced  Company  will  rely  on  to  complete  its  mission.  The  task 
analysis  was  organized  by  critical  functions,  with  the  primary  function  areas  being 
Intelligence,  Maneuver,  Eire  Support,  Command  and  Control,  and  Eogistics. 

b.  Company  Critical  Tasks 

The  purpose  of  any  information  exchange  is  to  help  rapidly  and  decisively 
execute  critical  tasks.  The  following  is  a  list  of  those  tasks  deemed  critical  to  mission 
success  by  the  NRL  report.^ 

Intelligence: 

1)  Collect  Information 

2)  Disseminate  Intelligence 

Maneuver: 

3)  Conduct  Tactical  Movement 

4)  Engage  Enemy  with  Direct  Eire  and  Maneuver 

Fire  Support: 

5)  Employ  Mortars 

6)  Employ  Close  Air  Support 

7)  Employ  Eield  Artillery 

^  Coyne,  et  al.,  Final  Report:  Company  and  Below  Command  and  Control  Information  Exchange 
Study  (Washington  D.C.:  Naval  Research  Laboratory,  2006). 

7  Ibid. 
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8)  Employ  Naval  Gunfire 

9)  Coordinate,  Synehronize  and  Integrate  Fire  Support 
Command  and  Control: 

10)  Plan  for  Combat  Operations 

11)  Direet  and  Lead  Unit  during  Preparation  for  the  Battle 

12)  Direet  and  Lead  Units  in  Exeeution  of  Battle 

Logistics: 

13)  Handle  Combat  Support  Issues  (e.g.,  easualties,  supply,  POWs) 


2,  Information  Exchanges  Where  Company  is  a  Node 

Table  1  gives  a  brief  synopsis  of  the  speeifie  lERs  generated  by  the  NRL  in  whieh 
the  Company  Combat  Operations  Center  (COC)  is  expeeted  to  be  a  node.*  The 
exehanges  ean  oeeur  either  up  to  the  battalion,  down  to  the  platoon  eommander  or  to 
adjaeent  or  supporting  units.  A  detailed  deseription  of  eaeh  information  exehange  and 
the  HSI  Laboratory  suggested  method  and  means  of  dissemination  is  provided  in  Chapter 
III,  Paragraph  A.2.b;  Experiment  Speeifies. 

The  offieer  leadership  of  the  1st  Battalion,  7th  Marine  Regiment,  stationed  aboard 
MCB  Twenty-nine  Palms,  California,  were  interviewed  in  person  and  provided  the  list  of 
lERs  in  Table  1.  Those  offieers,  ineluding  the  Battalion  Commanding  Offieer, 
Operations  Offieer,  Assistant  Operations  Offieer,  Alpha  Company  Commander  and  the 
Intelligenee  Offieer  were  asked  to  validate  the  list  by  indieating  whether  or  not  the  traffie 
would  aetually  be  sent,  how  often  the  traffie  would  be  sent,  and  if  the  HSI  laboratory’s 
suggested  method  and  means  of  dissemination  was  valid. 


*  Coyne,  et  al.,  Final  Report:  Company  and  Below  Command  and  Control  Information  Exchange 
Study,  (Washington  D.C.:  Naval  Research  Laboratory,  2006). 
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INE#  lER  # 

SHORT  TITLE 

GOAL 

1 

1.2.1 

Situation  Report  (SITREP) 

Pass  important  information  through  the  chain  of  command 

2 

1.2.2 

Report  Enemy  Activity 

Report  enemy  sighting  and  movement  up  the  chain  of  command 

3 

1.5 

Urgent  Unformatted 

Provide  information  on  current  situation  which  requires  immediate  action 

4 

1.6 

Routine  Unformatted 

Provide  information  which  may  not  require  immediate  action 

5 

2.2 

Distribute  Intel,  to  lower 

Pass  relevant  intelligence  down  the  chain  of  command 

6 

2.4 

Request  for  Information  (RFI) 

Pass  on  intelligence  need 

7 

2.5 

Request  for  Intel. 

The  Platoon  Commander  or  above  requests  specific  intelligence  from  Battalion 

8 

3.1 

Issue  FRAGGO 

Provide  fragment  of  Operation  Order  with  Commander's  intent  to  lower  levels 

9 

3.2 

Position  Report  at  Check  Point 

Provide  confirmation  of  arrival  at  designated  area  or  next  checkpoint 

10 

6.2 

Call  for  Fire  (Artillery) 

Request  for  fire  support  from  the  Artillery  Fire  Direction  Center  (FDC) 

11 

6.3 

Message  to  Observer  (Artillery) 

Provide  observer  with  basic  information  regarding  artillery  support 

12 

6.4 

Shot  /  Splash  Calls  (Artillery) 

Round  is  released  on  target  based  on  call  for  fire 

13 

6.5 

Adjust  Fire  (Artillery) 

Redirect  artillery  fire  so  it  is  on  target 

14 

6.6 

Report  Effects  (Artillery) 

Inform  Fire  Direction  Center  (FDC)  of  effect  on  the  target 

15 

7.2 

Request  Air  from  FSCC 

Request  to  Fire  Support  Coordination  Center  for  air  asset  support 

16 

7.4 

9-Line  Brief  (Close  Air  Support) 

Air  asset  and  observer  coordinate  attack  to  neutralize  target 

17 

7.5 

Check-in  (Close  Air  Support) 

The  observer  makes  visual  contact  with  the  air  asset  and  confirms  the  target 

18 

7.6 

BDA  (Close  Air  Support) 

Report  Battle  Damage  Assessment  of  attack  on  target 

19 

8.1 

Call  for  Fire  (NSFS) 

Round  is  release  on  target  based  on  call  for  fire. 

20 

8.2 

MTO  (NSFS) 

Provide  observer  with  basic  information  regarding  NSFS  support 

21 

8.3 

Shot  /  Splash  Calls  (NSFS) 

Round  is  released  on  target  based  on  call  for  fire 

22 

8.4 

Adjust  Fire  (NSFS) 

Redirect  NSFS  fire  so  it  is  on  target 

23 

8.5 

Report  Effects  (NSFS) 

Inform  Fire  Direction  Center  (FDC)  of  effect  on  the  target 

24 

10.1 

Issue  WARNO 

A  Warning  Order  is  issued  to  allow  a  unit  to  prepare  for  an  upcoming  order 

25 

11.1 

Bn  Issues  OPORD 

Company  Commander  receives  the  Operation  Order  from  the  Battalion 

26 

13.1.2 

Supply  Request  from  CSS  Unit 

Acquire  supplies  from  the  Battalion's  Combat  Service  Support  Unit 

27 

13.2.1 

Casualty  Report  (CASREP) 

Inform  higher  of  wounded  members 

28 

13.2.2 

Casualty  Evacuation 

(CASEVAC)  Request 

Have  a  serious  casualty  moved  from  the  battlefield  for  immediate  care 

29 

13.2.3 

Bn  Responds  to  CASEVAC 

Provide  information  to  the  CASEVAC  requester  on  how  evacuation  will  occur 

30 

13.2.4 

CASEVAC  Asset  Responds 

Inform  small  unit  leader  of  inbound  CASEVAC  unit  and  coordinate  pick  up 

Table  1 .  Summary  List  of  lERs  in  which  Company  is  a  Node 
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B,  INTERVIEW  SUMMARY 

1,  Recent  Combat  History  of  1st  Battalion,  7th  Marines 

First  Battalion,  7th  Marines  first  deployed  to  Iraq  in  Mareh  of  2003.  The  Battalion 
saw  signifieant  eornbat  aetion  in  its  movement  towards  Baghdad  and  in  the  streets  of  the 
Iraqi  eapital.  In  April,  the  Battalion  turned  over  eontrol  of  their  seetor  to  the  US  Army 
and  took  up  positions  in  the  eity  of  An  Najaf.  The  battalion  redeployed  to  Twenty-nine 
Palms,  CA  in  October  2003.  In  August  2004,  the  battalion  deployed  to  Western  Iraq  in 
support  of  Operation  Iraqi  Freedom  II.  There  the  battalion  conducted  security  operations 
in  the  cities  and  roadways  along  the  Euphrates  River  and  Syrian  border  to  include 
Husaybah,  Karabilah,  Sadah,  Ubaydi,  A1  Qa'im,  Haditha,  Hit  and  Haqlania.  Involved  in 
combat  operations  on  a  daily  basis,  the  battalion  conducted  mounted  and  dismounted 
urban  patrols,  cordon  knocks.  Main  Supply  Route  (MSR)  security,  sweep  operations,  and 
border  security  in  the  battalion’s  Area  of  Operation  (AO).  From  February  through 
September  2006,  1st  Battalion,  7th  Marines  deployed  to  the  A1  Qa’im  Region  in  Western 
Iraq.  The  battalion  occupied  fifteen  platoon  and  company  battle  positions,  which 
controlled  over  5,000  square  miles  in  the  Western  Euphrates  River  Valley.  Each  platoon, 
paired  with  an  Iraqi  Army  platoon  and  members  of  the  local  constabulary,  yielded 
tremendous  impact  on  security  throughout  the  A1  Qa’im  region  and  in  so  doing,  created 
the  model  for  Dispersed  Operations  throughout  the  Iraq  Theater.  ^ 

In  addition  to  the  Battalion’s  extensive  combat  experience  and  familiarity  with 
dispersed  operations,  all  of  the  officers  interviewed  in  Twenty-nine  Palms  also  had 
combat  experience  either  in  Iraq  during  OPERATION  IRAQI  EREEDOM  (OIE)  or 
Afghanistan  during  OPERATION  ENDURING  EREEDOM  (OEE).  Of  note,  the 
Battalion’s  current  operations  officer,  Capt  Jeremiah  Salame,  a  company  commander 
during  the  2006  deployment,  operated  from  a  Eorward  Operating  Base  in  which  his 


9  “1/7  History,”  r‘  Battalion,  7‘'‘  Marines,  http://www.i-mef.usmc.mil/div/7mar/lbii/history.asp 
(accessed  August  20,  2008). 
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company  was  located  at  distances  that  served  to  isolate  the  eompany  from  higher 
headquarters  and  the  ease  at  whieh  that  headquarters  provided  traditional  support, 

2.  Warfighter  Feedback 

First  Battalion,  7th  Marines  is  eurrently  in  an  intensive  training  phase  to  inelude 
partieipation  in  numerous  field  exereises,  firearms  training,  small  unit  taetics  and  many 
other  aetivities  in  preparation  for  an  upeoming  deployment  in  support  of  eurrent 
eontingeneies.  This  demanding  sehedule  has  preeluded  the  unit  from  participating  fully 
in  the  researeh  assoeiated  with  this  thesis.  Although  the  offieers  were  not  able  to  provide 
input  via  a  formal  survey  they  did  provide  some  valuable  insight  during  face  to  faee 
interviews  eonducted  at  their  headquarters  in  August.  Unfortunately  and  shortsightedly, 
no  time  was  allowed  to  interview  other  units  that  perhaps  would  have  be  able  to 
aeeommodate  the  research  involved. 

The  essenee  of  the  feedbaek  received  from  the  officers  of  1st  Battalion  was  that 
any  list  of  required  lERs  tend  to  be  customized  by  the  small  unit  leader  based  on 
personality,  assigned  mission  and  operating  area.  In  general,  most  lERs  are  part  of  SOP 
or  based  on  doetrine,  sueh  as  Casualty  Evacuation  requests,  ealls  for  fire,  and  requests  for 
re-supply.  There  are  other  exehanges  whose  format  and  frequency  depend  on  the 
preferenees  of  the  small  unit  leader  or  higher  headquarters.  Where  one  partieular 
operating  environment  may  support  the  display  of  a  Common  Operating  Pieture,  to 
inelude  both  hostile  and  friendly  traeks,  on  a  big  sereen  television  there  may  be  other 
instances  where  the  eompany  commander  will  have  to  rely  on  a  laminated  map  and  semi¬ 
permanent  markers  to  maintain  situational  awareness  of  the  friendly  and  hostile  situation. 
There  exists  no  line  item  list  of  lERs  and  their  assoeiated  method  of  display  to  date. 

During  the  interview,  a  point  was  made  regarding  why  “video”  or  “ehat”  was 
required  for  the  isolated  deeision  maker.  It  was  hypothesized  that  those  partieular 
methods  of  information  exehange  were  less  useful  for  the  small  unit  leader  executing 
tactical  tasking  then  it  was  for  higher  headquarters  or  even  high  level  deeision  makers 

Capt  Salame  (1/7  Battalion  Operations  Officer),  interview  by  Maj  Senn,  1/7  Headquarters,  Twenty- 
nine  Palms,  CA,  August  19,  2008. 
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located  “back  in  CONUS”  to  monitor,  in  real  time,  the  battlefield  half  a  world  away. 
There  appeared  to  be  a  hesitaney  to  embraee  any  teehnology  that  would  allow  those 
higher  echelons  the  temptation  of  micro-managing  small  unit  actions  from  behind  a 
plasma  sereen.  Another  point  of  emphasis  during  the  interview  was  the  second  and  third 
order  effeets  on  the  Table  of  Organization  (T/0)  and  Table  of  Equipment  (T/E)  fielding 
new  eommunieations  teehnology  at  the  eompany  level  and  below,  in  other  words,  sueh 
technology  would  require  more  manpower,  more  training,  and  more  support  equipment. 

Einally,  although  not  formally  reeorded  using  standardized  survey  forms,  the 
informal  feedbaek  reeeived  regarding  the  MCWL  lERs  generally  validated  that  eaeh  of 
the  thirty  lERs  summarized  in  Table  1  were  legitimate  reports,  requests,  and  eoordinating 
efforts.  Based  on  the  Battalion’s  experienee  in  the  EOB  environment  however,  the 
laboratory  suggested  method  of  broadeasting  the  reports  via  a  eonventional  Radio 
Erequeney  (RE),  either  the  PRC-117  or  PRC-105  radio  set,  was  dropped  in  favor  of 
software  applications  similar  to  those  in  the  MCWL  draft  for  the  Company  Level 
Operations  Center. 
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III.  FIELD  EXPERIMENTATION 


A.  EXPERIMENTATION  METHODOLGY 

The  original  intent  for  the  Limited  Objective  Experiment  was  to  test  a  validated 
list  of  lERs  derived  from  the  MCWL  lER  study  over  the  network  architecture  proposed 
in  the  MCWL  draft  Company  Level  Operations  Center  concept  documents.  Using  the 
proposed  CLOC  battle  rhythm  and  its  associated  sixteen  daily  reports  (see  Chapter  III, 
Paragraph  A.2.b)  to  higher,  adjacent,  and  subordinate  units  as  the  baseline  for 
information  exchanges,  data  would  be  collected  to  include  throughput,  transaction  rate, 
and  response  time.  Various  information  exchange  scenarios  would  be  run  in  addition  to 
the  baseline  reports  to  increase  network  traffic  until  maximum  throughput  was  achieved. 
However,  due  to  a  lack  of  access  to  the  proposed  CLOC  applications  or  data  regarding 
those  applications  the  experiment  involved  evaluation  of  the  network  using  a 
commercially  available  software  application  called  IX  Chariot®  (by  IXIA™),  to  simulate 
various  types  of  data  traffic  between  two  nodes  (see  Appendix  B  for  more  information 
regarding  the  software).  No  two  data  type  tests,  or  “scripts,”  were  run  concurrently  and 
no  encryption  was  applied,  however,  the  experiment  provides  a  set  of  reference  data  on 
how  certain  types  of  application  layer  data  may  effect  communication  via  a  SATCOM 
link. 

Initial  assumptions  made  to  support  the  experiment  included: 

1 .  SATCOM  (or  MILSATCOM)  coverage  is  available  in  the  AOR. 

2.  Company  node  deployed  beyond  doctrinal  distances  and  beyond  LOS  RE 
communication  equipment  capabilities;  dictating  the  use  of  SATCOM  as 
the  sole  means  to  pass  lERs. 

3.  SATCOM  configuration  is  a  point  to  point  connection  over  a 
commercially  available,  small  aperture  satellite  communication  terminal, 
with  a  network  configuration  downstream  of  the  SATCOM  terminal 
similar  to  that  in  the  MCTOG  concept  document. 
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4.  Company  has  established  a  Company  Level  Operations  Center  in  a 
Forward  Operations  Base  configuration,  operating  according  to  the 
MCTOG  concept  battle  rhythm  and  is  passing  the  MCWL  defined  list  of 
lERs. 

In  addition  to  measuring  data  regarding  lERs,  another  Master’s  degree  candidate 
conducted  concurrent  experiments  regarding  Simple  Network  Management  Protocol 
(SNMP)  over  the  experimental  network.  The  effects  of  the  SNMP  experiment  on  the 
EOE  will  be  discussed  in  section  2  of  this  chapter. 

All  experiments  were  conducted  at  the  Marine  Corps  Tactical  Systems  Support 
Activity,  located  on  board  MCB  Camp  Pendleton,  California.  MCTSSA  generously 
donated  previously  leased  satellite  airtime,  a  cost  that  would  have  otherwise  been 
prohibitive  to  the  conduct  of  theses  experiments. 

1.  Experiment  Scenario 

The  scenario  simulated  in  the  EOE  consisted  of  a  Point-to-Point  (P2P)  connection 
between  a  battalion  COC  and  a  EOB  CEOC  over  a  geostationary  (GEO)  satellite  utilizing 
two  small  aperture  satellite  terminals.  A  single  workstation  at  the  battalion  COC  would 
interact  with  a  single  workstation  at  the  company  COC,  executing  various  types  of 
information  exchanges  one  would  expect  from  workstations  populated  with  the 
recommended  decision  making  software  applications.  Power  output  at  either  SATCOM 
terminal  would  be  limited  in  order  to  prevent  bleed-over  to  adjacent  channels  on  the 
leased  satellite  or  adjacent  satellites  in  geostationary  orbits  and  hence  there  was  no 
opportunity  to  increase  bandwidth  by  increasing  the  gain  of  either  terminal. 

2.  Experiment  Specifics 

The  following  paragraphs  will  detail  the  physical  configuration,  the  representative 
lERs  sent  on  the  network,  and  the  software  suite  used  for  the  experiment.  Definitions  of 
the  metrics  used  by  the  evaluation  software  to  produce  the  data  collected  will  also  be 
provided. 
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a.  Network  (Physical)  Configuration 

Figure  1  shows  the  MCWL  proposed  network  architecture  for  the  CLOC 
concept  of  employment.  The  Wide  Area  Network  (WAN)  consists  of  a  satellite  or 
terrestrial  communication  terminal  connected  to  the  “cloud,”  which  symbolizes  external 
communication  services,  such  as  the  internet  or  a  database  server.  Line  encryption 
between  the  communication  terminal  and  the  Layer  3  router  provides  security  while  the 
Layer  3  router  serves  as  the  cross  over  from  the  WAN  to  the  Local  Area  Network  (LAN). 
The  Layer  2  or  3  switch  distributes  information  packets  to  the  appropriate  node  on  the 
local  backbone. 


DRAFT  -  CLOC  CONCEPT  OF  EMPLOYMENT 

NETWORK  ARCHITECTURE 


\ 


\ 


\ 

1 

/ 


/ 


/ 


Figure  1 .  MCWL  Concept  Network  Architecture'’’’ 


11  MCWL,  DRAFT-CLOC  CONCEPT  OF  EMPLOYMENT,  (Quantico,  VA:  U.S.  Marine  Corps, 
2007). 
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Figure  2  shows  the  aetual  network  arehiteeture  used  during  the  LOE.  To 
establish  a  eommunieations  network,  two  Swe-Dish  IPT-I  Mil  Suitcase  terminals,  version 
2.4,  were  utilized  as  the  communication  terminal  at  both  the  battalion  and  company  COC. 
Connected  to  the  SATCOM  terminal  was  a  Cisco  2800  Router  in  line  with  a  Cisco 
Catalyst  2950  Switch  to  route  information  data  to  the  appropriate  node  on  the  LAN. 
Although  the  2800  routers  are  capable  of  Advanced  Encryption  Standard  (AES)  type 
encryption,  this  LOE  did  not  incorporate  that  capability. 


NOTES: 

1  No  encryption  on  router 

2.  P2P  only,  no  access  to  cloud  or  other 

services 


Point  to  Point  Connection 
Galaxy  27  @  129°  W 


Battalion  Node 


Swe-Dish  IPT-i  Mil  Suitcase  2.4 
(0.9m  dish) 

iDirect  Modem:  192.168.1.1/30 


Cisco  2800  Router 
(Layer  3) 

Loopback:  192. 168. 1.56/32 
Interface  to  switch:  192.168.1 .65 
Network:  192.168.1.64/27 
Gateway:  192.168.1.2/30 


Cisco  Catalyst  2950  Switch 
(Layer  2) 

Switch  VLAN  1 
192.168.1.66 


LAN 


192.168.1.70/27 

low  1 


192.168.1.69/27 

low  2 


Company  Node 


Swe-Dish  IPT-i  Mil  Suitcase  2.4 
(0.9m  dish) 

iDirect  Modem:  192.168.2.1/30 


Cisco  2800  Router 
(Layer  3) 

Loopback:  192.168.2.56/32 
Interface  to  switch:  192.168.2.65 
Network:  192.168.2.64/27 
Gateway:  192.168.2.2/30 


Cisco  Catalyst  2950  Switch 
(Layer  2) 

Switch  VLAN  1 
192.168.2.66 


LAN 


192.168.1.68/27 
SNMP  Management 
Console 


192.168.2.68/27 

low  1 


192.168.2.69/27 
low  2 


192.168.2.70/27 
IX  Chariot 
Console  y 


Figure  2. 


LOE  Network  Arehiteeture 
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At  the  battalion  node,  one  workstation  served  as  the  SNMP  management 
eonsole,  while  a  workstation  at  the  eompany  node  served  as  the  IX  Chariot  console,  or 
controlling  node.  Various  other  workstations  at  both  the  battalion  and  company  node 
acted  as  IX  Chariot  “endpoints,”  which  will  be  described  in  the  Paragraph  1  .c  to  follow. 

The  Swe-Dish  IPTs,  on  loan  from  the  Naval  Postgraduate  School’s  Center 
for  Network  Innovation  and  Experimentation  (CENETIX),  are  Ku  band  (12-18  GHz) 
terminals  with  0.9m  diameter  Gregorian  offset  dishes.  The  system  advertises  a  capability 
of  a  2Mbps  duplex  transmission  of  IP  standard  data,  voice  and  video.  Using  MPEG2 
video  encoding  the  IPT  Suitcase  provides  broadcast  picture  quality.  With  its  10/100  base- 
T  port,  the  system  works  as  an  ordinary  LAN  for  email,  ETP,  VoIP  and  data  streams.  An 
L-band  port  is  optional. Por  additional  technical  information  on  the  Swe-Dish  IPTs,  see 
Appendix  A. 


b.  Information  Exchanges  and  Application  Configuration 

As  previously  discussed,  the  intent  of  the  LOE  was  to  test  a  particular  set 
of  lERs  over  a  specific  network  configuration  to  determine  the  feasibility  that  such  a 
network  could  support  the  information  exchanges.  The  example  battle  rhythm,  excerpted 
directly  from  MCWL’s  CLOC  Concept  of  Employment  (2007),  will  serve  as  a  baseline 
requirement  for  the  amount  and  frequency  of  information  exchanges  occurring  at  the 
company  level. 

EXAMPLE  BATTLE  RHYTHM 

A  24-hour  battle  rhythm  may  include  the  following  activities: 

2345  Watch  Officer  change  over 

2345  Radio  Watch  change  over 

0000  CONOPS  report  due  to  Bn 

0000  Ops/Intel  NCO  print  digital  watch  log  and  place  in  binder 

0530  Platoon  POSREPs  due  to  Co 


Instructions  for  Use,  IPT-I  Mil  Suitcase  2.4,  Satellite  Communications  Terminal  featuring  iDirect, 
CD-ROM,  SWE-DISH  Satellite  Systems  AB,  2007. 
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0545  Ops  /  Intel  NCO  change  over 

0600  Platoon  personnel  updates  due  to  Co 

0630  Platoon  LOGSTATS  due  to  Co 

0630  Co  POSREPs  due  to  Bn 

0645  Company  ECP  status  reports  due  to  Bn 

0730  Intel  (collections)  change  over 

0745  Watch  Officer  change  over 

0745  Radio  Watch  change  over 

0745  Intel  (analysis)  change  over 

0800  CONOPS  report  due  to  Bn 

1130  Platoon  POSREPs  due  to  Co 

1200  Intentions  message  due  to  Bn 

1230  Co  POSREPs  due  to  Bn 

1345  Ops  /  Intel  NCO  change  over 

1400  Co  personnel  updates  due  to  Bn 

1400  Company  personnel  updates  due  to  Bn 

1430  Company  EOGSTATS  due  to  Bn 

1430  Bn  POSREPs  due  to  Regt 

1445  Company  ECP  status  reports  due  to  Bn 

1530  Intel  (collections)  change  over 

1545  Watch  Officer  change  over 

1545  Radio  Watch  change  over 

1545  Intel  (analysis)  change  over 

1930  Platoon  POSREPs  due  to  Co 

2000  Intentions  message  due  to  Bn 

2030  Co  POSREPs  due  to  Bn 

2200  Bn  Personnel  Stats  due  to  Regt 

2345  Watch  Officer  change  over 
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Once  the  baseline  is  tested,  the  amount  and  frequeney  of  exchanges  will 
be  inerementally  inereased  by  simultaneously  sending  various  information  exehange 
scenarios  along  with  the  previously  discussed  baseline.  Detailed  listings  of  those 
information  exehanges,  excerpted  from  the  U.S.  Naval  Research  Laboratory  Final 
Report:  Company  and  Below  Command  and  Control  Information  Exchange  Study 
(2006),  are  ineluded  below. 

DETAILED  INFORMATION  EXCHANGE  REQUIRMENTS 

1.2,1  Provide  a  Situation  Report  (SITREP) 

Goal:  Pass  important  information  through  the  ehain  of  command. 

Description:  Report  information  up  the  chain  of  command  and  horizontally 
when  it  is  either  eritieal,  or  an  opportunity  has  presented  itself  to  provide  a  larger 
report  of  less  eritieal  items. 

Communication: 


Sender:  Reeeiver:  Monitor:  Network: 

Potential 

Exehanges: 

FTLDR  SQDLDR  Other  FT  LDRs  Squad  Net 

SQDLDR  PFTCDR  Other  SQD  LDRs  Platoon  Net 

PLTCDR  Co  CO  Other  PLTCDRs  Company  Net 

Co  CO  BN  CDR  Other  Co  Cos  Battalion  Net 

Information 

Anything  unusual  sueh  as  trash  that  has  not  been  pieked  up, 
potential  lEDs.  The  formality  of  the  exchange  will  depend  on 
proximity,  urgency,  and  experience.  The  exchange  is  more  likely  to 
be  formal  at  higher  levels  of  eommand  as  more  information  is 
fdtered  out. 

Purpose: 

Provide  battlefield  information  to  higher  level  of  command  and 
others  at  the  same  level  of  command. 

Potential 

Problems: 

Range  limitations. 

HSI 

Reeommended 

Recommended  Format 

Reeommended  System 

PFT  CDR:  Voiee  Comms 

Co  CO:  Voiee  Comms 

AN/PRC- 150  w/  D-D  ACT 
AN/PRC-1 17F  (SATCOM) 
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1.2.2  Report  Enemy  Activity  (SALUTE) 

Goal:  Report  Enemy  Sighting  and  Movement  up  the  chain  of  command. 
Description:  Report  information  up  the  chain  of  command  and  horizontally 
regarding  enemy  sightings  and  movement.  Information  reported  contains  the 
enemy  size,  activities,  location,  unit  identification,  time,  and  equipment. 
Communication: 


Sender:  Receiver:  Monitor:  Network: 

Potential 

Exchanges 

SQDEDR  PETCDR  Other  SQD  EDRs  Platoon  Net 

PETCDR  Co  CO  Other  PET  CDRs  Company  Net 

Co  CO  BNCDR  Other  Co  COs  Battalion  Net 

Information 

The  formality  of  the  exchange  will  depend  on  proximity,  urgency, 
and  experience.  The  exchange  is  more  likely  to  be  formal  at  higher 
levels  of  command  as  more  information  is  filtered  out.  A  SALUTE 
Report  contains  Size  of  enemy  force.  Activities  of  the  enemy. 
Location  of  enemy.  Unit  identification.  Time,  and  Equipment  carried 
by  enemy. 

Purpose: 

Provide  intelligence  on  enemy  movement  to  higher  level  of 
command  and  others  at  the  same  level  of  command. 

Potential  Problen 

Range  limitations. 

HSI 

Recommended 

Recommended  Eormat 

Recommended  System 

Pit  CDR:  Visual  /  Graphical 

Co  CO:  Visual  /  Graphical 

AN/PRC- 150  w/  D-D  ACT 
AN/PRC-1 17P  (SATCOM) 

1.5  Urgent  Unformatted  Reports 

Goal:  Provide  information  on  current  situation  which  requires  immediate  action 
Description:  This  is  a  generic  communication  for  transmitting  urgent 

information.  It  can  be  passed  either  up  or  down  the  chain. 

Communication: 


Sender: 

Receiver: 

Monitor: 

Network: 

Potential  Exchanj 

Bn 

Co  CO 

Other  PET  CDRs 

Battalion  Net 

CoCO 

PET  CDR 

Other  PET  CDRs 

Company  Net 

PET  CDR 

SQD  LDR 

Other  SQD  EDRs 

Pit  Net 

SQD  LDR 

ET  LDR 

Other  ET  EDRs 

Sqd  Net 

Information 

The  is  a  generic  communication  type  and  is  used  when  urgent 
information  needs  to  be  reported  immediately  up  or  down  the  chain 
of  command.  An  example  is  a  request  for  support. 

Purpose: 

Provide  actionable  information  to  designated  units. 

Potential  Problem 

Range  limitations. 

HSI 

Recommended 

Recommended  Eormat 

Recommended  System 

PET  CDR:  Voice  Comms 

Co  CO:  Voice  Comms 

AN/PRC- 150  w/  D-D  ACT 
AN/PRC- 1 17P  (SATCOM) 
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1,6  Routine  Unformatted  Reports 

Goal:  Provide  regular  information  on  eurrent  situation  whieh  may  not  require 
immediate  aetion 

Description:  This  is  a  generic  communication  for  transmitting  regular 

information.  It  can  be  passed  either  up  or  down  the  chain. 

Communication: 


Sender: 

Receiver: 

Monitor: 

Network: 

Potential  Exchanj 

Bn  CDR 

Co  CO 

Other  Cc  COs 

Battalion  Net 

Co  CO 

PLT  CDR 

Other  PLT  CDRs 

Company  Net 

PLT  CDR 

SQD  LDR 

Other  SQD  LDRs 

Pit  Net 

SQD  LDR 

FT  LDR 

Other  FT  LDRs 

Sqd  Net 

Information 

The  is  a  generic  communication  type  and  is  used  when  regular 
information  needs  to  be  reported  immediately  up  or  down  the  chain 
of  command.  An  example  is  a  request  for  support. 

Purpose: 

Provide  information  to  designated  units. 

Potential  Problem 

Range  limitations. 

HSI 

Recommended  Format 

Recommended  System 

Recommended 

PLT  CDR:  Voice  Comms 

Co  CO:  Voice  Comms 

AN/PRC- 150  w/  D-D  ACT 
AN/PRC- 1 17F  (SATCOM) 

2.2  Distribute  Intelligence  to  Lower  Level  of  Command 

Goal:  Pass  relevant  intelligence  down  the  chain  of  command 
Description:  Report  relevant  battlefield  intelligence  down  the  chain  of 

command.  This  will  allow  the  lower  levels  of  command  to  maintain  a  battlefield 
Situation  Awareness.  Actionable  intelligence  will  be  sent  down  the  chain 
immediately. 

Communication: 


Sender:  Receiver:  Monitor:  Network: 

Potential 

Exchanges: 

Co  CO  PLT  CDR  Other  PLT  CDRs  Company  Net 

PLT  CDR  SQD  LDR  Other  SQD  LDRs  Platoon  Net 

SQD  LDR  FT  LDR  Other  FT  LDRs  Squad  Net 

Information 

There  is  no  official  format  for  intelligence  passed  down  the  chain  of 
command. 

Purpose: 

Provide  a  “heads  up”  to  lower  levels  of  command. 

Potential 

Problems: 

Range  limitations. 

HSI 

Recommended 

Recommended  Format 

Recommended  System 

Co  CO:  Visual/Graphical 

AN/PRC- 150  w/  D-D  ACT 
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2.4  Request  for  Information  (RFI) 

Goal:  Pit  CDR  /  Co  CDR  informs  the  Co  CDR  /  BN  of  an  intelligence  need. 
Description:  Subordinate  LDR  will  request  intelligence  from  higher. 

Communication: 


Sender:  Receiver:  Monitor:  Network: 

Potential 

Exchanges: 

PET  CDR  Co  CO  Other  PET  CDRs  Company  Net 

Co  CO  BN  CDR  Other  Co  CO  Battalion  Net 

Information 

Subordinate  EDR  informs  higher  of  what  information  they  need 

Purpose: 

Indicate  a  need  for  intelligence  to  higher 

Potential 

Problems: 

Range  limitations. 

HSI 

Recommended 

Recommended  Eormat 

Recommended  System 

Pit  CDR:  Voice 

Co  CO:  Voice 

AN/PRC- 150  w/  D-D  ACT 
AN/PRC- 1 17P  (SATCOM) 

2,5  Request  Intelligence  from  Battalion  S-2 

Goal:  The  Company  Commander  requests  specific  intelligence  from  the 

Battalion  S-2 

Description:  The  Platoon  Commander  goes  to  the  battalion  S-2  to  request  an 
intelligence  update.  The  Platoon  Commander  would  usually  only  go  direct  to 
Battalion  if  they  were  the  only  platoon  ashore. 

Communication: 


Sender:  Receiver:  Monitor:  Network: 

Co  CDR  Bn  S-2  N/A  Battalion  Net 

Information 

The  Company  CO  requests  specific  information  from  the  Bn  S-2. 

Purpose: 

Solicit  information  from  the  Bn-S2. 

Potential 

Problems: 

None  assuming  a  single  Platoon  ashore  with  the  Company  CO 
monitoring  communications  in  the  Battalion  Command  Operations 
Center  (COC).  Eeaving  the  Company  network  would  not  present  any 
problems  since  the  Company  Commander  will  still  be  able  to  monitor 
the  Platoon’s  communications. 

HSI 

Recommended 

Recommended  Eormat 

Recommended  System 

Co  CO:  Voice 

AN/PRC-1 17E  (SATCOM) 
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3,1  Issue  FRAG  Order 

Goal:  Provide  Mission  Order  with  Commander’s  Intent  to  lower  levels  of  command. 
Description:  The  Frag  order  is  a  fragment  of  the  Operation  Order  (OPORD).  It 
informs  lower  units  of  their  responsibilities  within  the  OPORD.  It  should  ideally 
leave  the  specific  details  to  the  lower  level  of  command.  For  example  the  Company 
CO  may  inform  a  Platoon  CDR  to  set  up  ambushes  within  a  general  area  and  where 
to  expect  enemy  movement.  The  Platoon  CDR  then  decides  where  to  place  the 
Squads  to  set  up  the  ambush. 


Communication : 


Sender:  Receiver:  Monitor:  Network: 

Potential 

Exchanges: 

Bn  CDR  Co  CO  Other  Co  COs  Battalion  Net 

Co  CO  PET  CDR  Other  PET  CDRs  Company  Net 

PET  CDR  SQDLDR  Other  SQD  LDRs  Platoon  Net 

SQDLDR  FTLDR  Other  FT  LDRs  Squad  Net 

Information 

Provide  information  on  the  mission  objective  and  the  commander’s 
intent,  but  allowing  flexibility  on  how  the  mission  will  be  carried  out. 
Ideally  this  should  contain  all  5  elements  of  SMEAC.  Situation  (enemy 
and  friendly  forces),  Mission,  Execution  (Commander’s  intent,  concept 
of  operation,  etc),  Administrative/Logistics,  Command/Signal. 

Purpose: 

Provide  an  objective  to  the  Marine  unit  without  necessarily  forcing  a 
specific  solution. 

Potential 

Problems: 

No  identified  problems 

HSI 

Recommended 

Recommended  Format 

Recommended  System 

Bn  CDR:  Visual  /  Graphical 

Co  CO:  Visual  /  Graphical 

AN/PRC- 1 17F  (SATCOM) 
AN/PRC- 150  w/  D-DACT 

3.2  Position  Report  at  Designated  Area/Check  Point 

Goal:  The  unit  moves  to  either  their  designated  area  or  their  next  checkpoint  and 
then  reports  in. 

Description:  Unit  provides  position  reports  to  keep  the  commanding  officer 
informed  on  where  the  unit  is  and  when  they  will  be  at  their  next  designated  area. 

Communication : 


Sender:  Receiver:  Monitor:  Network: 

Potential 

Exchanges: 

FTLDR  SQDLDR  Other  FT  LDRs  Squad  Net 

SQDLDR  PET  CDR  Other  SQD  LDRs  Platoon  Net 

PLTCDR  Co  CO  Other  PLT  CDRs  Company  Net 

Co  CO  Bn  CDR  Other  Co  COs  Bn  Net 

Information 

Identify  commanding  unit,  your  unit,  and  the  brevity  code  for  the 
check  point. 

Purpose: 

Update  your  commanding  unit  of  your  present  position. 

Potential 

Problems: 

Range  Limitations 

HSI 

Recommended 

Recommended  Format 

Recommended  System 

Co  CO:  Visual  /  Graphical 

PLT  CDR:  Visual  /  Graphical 

AN/PRC- 1 17F  (SATCOM) 
AN/PRC- 150  w/  D-DACT 
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6,2  Call  for  Fire  (Artillery) 

Goal:  Platoon  Commander  requests  fire  from  the  artillery  FDC 
Description:  Self  explanatory. 

Communication: 


Sender 

Receiver 

Monitor: 

Network: 

Potential 

Exchanges: 

Co  CO 

Arty  FDC 

Battalion  COF 

Information 

Standard  Call  For  Fire  (CFF)  format 

Purpose: 

Inform  FDC  about  target  so  that  artillery  can  be  employed 

Potential 

Problems: 

•  Information  is  being  relayed  from  initial  source.  Potential  for 
interpretation  errors  in  voice  data  transmission. 

•  Currently  need  to  talk  to  the  FDC  and  the  observer  on  two 
different  radios.  Cannot  have  one  listen  in  while  relaying 
information  to  the  other. 

•  The  Platoon  Commander  would  have  to  switch  off  the  company 
net  to  go  to  the  battalion  FSCC  net  as  both  use  the  PRC- 
119/150. 

•  Inform  FDC  of  where  fire  is  going  to  increase  the  splash  time. 

HSI 

Recommended 

Recommended  Format 

Recommended  System 

Co  CO:  Visual  /  Graphical 

AN/PRC- 150 

6,3  Message  to  Observer 

Goal:  Inform  the  observer  who  will  be  firing  and  what  the  volleys  in  effect  are. 
Description:  This  is  the  message  from  the  FDC  to  the  observer  that  details  who 
will  fire,  any  changes  to  the  CFF,  the  number  of  volleys  in  effect  and  the  target 
number. 

Communication: 


Sender:  Receiver: 

Monitor: 

Network: 

Potential 

Exchanges: 

Arty  Co  EST  Arty 

EDC  Rep 

Battalion  COP 

Information 

1.  Eiring  Unit 

2.  Changes/ Additions  to  the  CEE 

3.  Rounds  in  Effect  (Number  of  Volleys) 

4 .  T arget  Number 

Purpose: 

Notify  observer  of  any  changes  to  the  CEE  and  inform  them  of 
what  the  fire  will  be. 

Potential 

Problems: 

No  identified  problems 

HSI 

Recommended 

Recommended  Eormat 

Recommended  System 

Co  EST:  Voice 

AN/PRC- 150 
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6,4  Report  Shot  and  Splash 

Goal:  Notify  Company  Commander  of  incoming  rounds. 
Description:  Self  explanatory 

Communication: 


Sender:  Receiver: 

Monitor: 

Network: 

Potential 

Exchanges: 

Arty  Co  FST  Arty 

FDC  Rep 

Battalion  COF 

Information 

Shot  is  fired 

1 .  Arty  announce  shot  (i.e.,  “Shot  over”) 

2.  Company  acknowledges  (i.e.,  “Shot  out”) 

Ten  seconds  before  impact: 

3.  Arty  announces  “Splash  over” 

4.  Company  acknowledges  “Splash  out” 

Purpose: 

Notify  Company  of  shot  fired  and  its  predicted  impact. 

Potential 

Problems: 

No  identified  problems 

HSI 

Recommended 

Recommended  Format 

Recommended  System 

Co  FST:  Voice 

AN/PRC- 150 

6,5  Adjust  Fire  (Artillery) 

Goal:  Redirect  artillery  fire  so  it  is  on  target. 
Description:  Self  explanatory 

Communication: 


Sender 

Receiver 

Monitor: 

Network: 

Potential 

Exchanges: 

Co  FST 
Arty  Rep 

Arty  FDC 

Battalion  COF 

Information 

Notify  FDC  to  shift  fire  Feft/Right  and  Add  or  Drop 

1 .  Identification  (FDC  this  is  ) 

2.  Warning  Order  (either  adjust  fire,  fire  for  effect,  immediate 
suppression,  smoke,  SEAD) 

******FDC  reads  back  information******* 

3.  Focation  of  target  (shift) 

Purpose: 

Notify  FDC  to  adjust  mortar. 

Potential 

Problems: 

•  Range  limitations. 

HSI 

Recommended 

Recommended  Format 

Recommended  System 

Co  FST:  Voice 

AN/PRC- 150 
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6,6  Inform  FDC  of  artillery’s  effect. 

Goal:  Inform  FDC  of  artillery’s  effect  on  the  target. 
Description;  Self  explanatory 

Communication: 


Sender 

Receiver 

Monitor: 

Network: 

Potential 

Exchanges: 

Co  CO 

Arty  FDC 

Battalion  COF 

Information 

Notify  Artillery  that  the  target  has  been  d 
where  additional  fire  should  be  delivered. 

estroyed,  suppressed,  or 

Purpose: 

Provide  Artillery  with  a  BDA 

Potential 

Problems: 

•  Range  limitations  force  this  step  in  the  communication  process. 

HSI 

Recommended 

Recommended  Format 

Recommended  System 

Co  FST:  Voice 

AN/PRC- 150 

7,2  Request  air  asset  from  Fire  Support  Coordination  Center  (FSCC), 

Goal:  Company  commander  seeks  approval  from  FSCC  to  use  an  air  asset  to 
neutralize  an  identified  target. 

Description:  Company  commander  evaluates  the  request  for  air  and  uses  their 
experience  to  determine  whether  an  air  asset  should  be  used.  If  an  asset  should  be 
utilized,  they  “forward”  the  information  from  the  Platoon  CDR  to  the  FSCC. 

Communication: 


Sender 

Receiver 

Monitor: 

Network: 

Potential 

Exchanges: 

Co  EST 
Air  Rep 

ESCC  or 

SACC 

TAR/HR 

Information 

TAR.-  Unit  identifier,  priority,  mission,  payload,  instructions,  target 
type,  location,  assets  being  requested,  desired  ordnance/results,  etc. 

Purpose: 

Provide  ESCC  with  information  necessary  to  evaluate  call  for  air 
with  available  assets  and  target  priority.  If  necessary  allocate  the 
appropriate  asset. 

Potential 

Problems: 

•  Information  is  being  relayed  from  initial  source.  Potential  for 
interpretation  errors  in  voice  data  transmission. 

•  Currently  need  to  talk  to  the  ESCC  and  the  Observer/  Squad 
node  on  two  different  radios.  Cannot  have  one  listen  in  while 
relaying  information  to  the  other. 

•  If  Aircraft  is  not  available  ESCC  or  currently  under  the  ESCC’s 
control  they  may  need  to  keep  the  company  commander  on 
“hold”  thus  potentially  keeping  them  off  the  company  net. 

HSI 

Recommended 

Recommended  Eormat 

Recommended  System 

Co  EST;  Visual/Graphical 

AN/PRC- 1 17E  (SATCOM) 
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7,4  Air  Asset  and  Observer  coordinate  attack  (9  Line) 

Goal:  Neutralize  target. 

Description:  The  Observer  has  been  told  the  CFF  has  been  approved,  and  is 
provided  information  on  eontaeting  the  Air  Asset.  The  Observer  eommunieates 
with  asset  to  eoordinate  the  attaek  and  provides  a  standard  nine  line. 

Communication: 


Sender: 

Reeeiver: 

Monitor: 

Network: 

Potential 

Exehanges: 

Co  FST 
Air  Rep 

Air  Asset 

FSCC 

Air  Asset’s  Frequeney 

Information 

Standard  “9-Line”  Format 

Purpose: 

Provide  target  information  to  the  air  asset;  neutralize  the  target. 

Potential 

Problems: 

•  De-eonfiietion  with  other  forees  in  area  is  traditionally  done  at 
the  platoon  or  Co  level. 

HSI 

Reeommended 

Reeommended  Format 

Reeommended  System 

Co  FST:  Visual/Graphieal 
(w/  audio) 

AN/PRC- 150  with  D-D  ACT 

7.5  Air  Asset  Enters  Target  Area  and  Confirms  Target 

Goal:  The  observer  makes  visual  eontaet  with  the  air  asset  and  eonfirms  the 
target. 

Description:  The  air  asset  enters  into  the  designated  air  spaee  and  requests 
eonfirmation  from  the  observer.  The  observer  visual  identifies  the  air  asset  is 
lined  up  and  eonfirms  the  attaek. 

Communication: 


Sender: 

Reeeiver: 

Monitor: 

Network: 

Potential 

Exehanges: 

Co  EST 
Air  Rep 

Air  Asset 

ESCC 

Air  Asset’s  Erequeney 

Information 

•  Aireraft  will  announee  that  they  are  inbound  and  distanee  from 
target 

•  Observer  will  inform  aireraft  to  eontinue 

•  Observer  will  inform  aireraft  of  where  the  target  is  from  the 
mark. 

•  Aireraft  goes  into  “the  pop”  and  observer  eonfirms  airerafts 
loeation. 

•  Aireraft  goes  “wings  level”  and  proeeeds  to  target 

•  Observer  eonfirms  aireraft  is  inbound  to  target  and  announees 
“Cleared  Hot” 

Purpose: 

Confirm  target  loeation  and  direet  aireraft  to  the  target. 

Potential 

Problems: 

No  identified  problems 

HSI 

Reeommended 

Reeommended  Eormat 

Reeommended  System 

Co  EST:  Voiee 

AN/PRC- 150  with  D-D  ACT 
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7,6  Observer  reports  Battle  Damage  Assessment  (BDA)  of  target  back  to  Air  Asset. 
Goal:  Report  effectiveness  of  attack. 

Description:  The  Observer  communicates  with  Air  Asset  to  report  damage  to 
target. 

Communication: 


Sender: 

Receiver: 

Monitor: 

Network: 

Potential 

Exchanges: 

Co  FST 
Air  Rep 

Air  Asset 

FSCC 

Air  Asset’s  Frequency 

Information 

Target  neutralized,  damage  assessment,  new  coordinates,  etc. 

Purpose: 

Provide  damage  information  to  the  Air  Asset 

Potential 

Problems: 

•  Aircraft  may  leave  the  area  (range  issue) 

HSI 

Recommended 

Recommended  Format 

Recommended  System 

Co  FST:  Voice 

AN/PRC- 150  with  D-D  ACT 

8,1  Call  for  Fire  (Naval  Gunfire) 

Goal:  The  company  commander  requests  fire  from  Naval  Guns 
Description:  Self  explanatory 

Communication: 


Sender 

Receiver 

Monitor: 

Network: 

Potential  Exchanges: 

Co  CO 

Naval  FDC 

? 

Information 

Standard  Call  For  Fire  Format 

Purpose: 

Inform  FDC  about  target  so  that  artillery  can  be  employed 

Potential  Problems: 

•  Information  is  being  relayed  from  initial  source.  Potential  for 
interpretation  errors  in  voice  data  transmission. 

•  Inform  FDC  of  where  fire  is  going  to  increase  the  splash  time. 

HSI  Recommended 

Recommended  Format 

Recommended  System 

Co  FST:  Voice 

AN/PRC-1 17F  (SATCOM) 
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8,2  Message  to  Observer 

Goal:  Inform  the  observer  who  will  be  firing  and  what  the  volleys  in  effeet  are. 
Description:  This  is  the  message  from  the  FDC  to  the  observer  that  details  who 
will  be  firing,  any  changes  to  the  CFF,  the  number  of  volleys  in  effect,  and  the 
target  number. 

Communication: 


Sender:  Receiver: 

Monitor: 

Network: 

Potential 

Exchanges: 

Naval  Co  CO 

FDC 

Information 

1.  Firing  Unit 

2.  Changes/ Additions  to  the  CFF 

3.  Rounds  in  Effect  (Number  of  Volleys) 

4 .  T arget  Number 

Purpose: 

Notify  observer  of  any  changes  to  the  CEE  and  inform  them  of 
what  the  fire  will  be. 

Potential  Problems: 

No  identified  problems 

HSI  Recommended 

Recommended  Eormat 

Recommended  System 

Co  EST:  Voice 

AN/PRC- 1 17E  (SATCOM) 

8,3  Splash  and  Shot  (Naval  Gunfire) 

Goal:  Round  is  released  on  target  based  upon  CFF 

Description:  Naval  gun  battery  fires  round  and  FDC  announces  shot  and  splash. 
The  Announcement  is  passed  down  the  chain  to  the  observer. 

Communication: 


Sender:  Receiver: 

Monitor: 

Network: 

Potential 

Exchanges: 

Naval  EDC  Co  CO 

Co  CO  PET  CDR 

Other  PET  CDRs 

Company  Net 

Information 

Shot  is  fired 

1.  EDC  announces  shot  (i.e.,  “Shot  over”) 

2.  Co  CO  acknowledges  (i.e.,  “Shot  out”) 

3.  Co  CO  announces  shot  (i.e.,  “Shot  over”) 

4.  PET  CDR  acknowledges  (i.e.,  “Shot  out”) 

Eifteen  seconds  before  impact: 

5.  EDC  announces  “Splash  over” 

6.  Co  CO  acknowledges  “Splash  out” 

Ten  Seconds  before  impact: 

7.  Co  CO  announces  “Splash  over” 

8.  PET  CDR  acknowledges  “Splash  out” 

Purpose: 

Notify  Platoon  of  shot  fired  and  its  predicted  impact. 

Potential 

Problems: 

No  identified  problems 

HSI 

Recommended 

Recommended  Eormat 

Recommended  System 

Co  EST:  Voice 

PET  CDR:  Voice 

AN/PRC- 1 17E  (SATCOM) 
AN/PRC- 150 
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8,4  Adjust  Fire  (Naval  Gunfire) 

Goal:  Redirect  Naval  gunfire  so  it  is  on  target. 
Description:  Self  explanatory 

Communication: 


Sender  Receiver 

Monitor: 

Network: 

Potential 

Exchanges: 

PET  CDR  Co  CO 

Other  PET  CDRs 

Company  Net 

Co  CO  Naval  EDC 

Information 

Notify  EDC  to  shift  fire  Eeft/Right  and  Add  or  Drop 

1 .  Identification  (EDC  this  is  ) 

2.  Warning  Order  (either  adjust  fire,  fire  for  effect,  immediate 
suppression,  smoke,  SEAD) 

******EDC  reads  back  information******* 

3.  Eocation  of  target  (shift) 

Purpose: 

Notify  EDC  to  adjust  fire. 

Potential 

Problems: 

Range  limitations. 

HSI 

Recommended 

Recommended  Eormat 

Recommended  System 

Co  EST:  Voice 

PET  CDR:  Voice 

AN/PRC- 1 17E  (SATCOM) 
AN/PRC- 150 

8,5  Report  on  Rounds  Effect  (Naval  Gunfire) 

Goal:  Provide  information  up  the  chain  of  command  regarding  effectiveness  of 
naval  gunfire. 

Description:  Self  explanatory 

Communication: 


Sender  Receiver 

Monitor: 

Network: 

Potential 

Exchanges: 

PET  CDR  Co  CO 

Other  PET  CDRs 

Company  Net 

Co  CO  Naval  EDC 

Information 

Notify  up  the  chain  of  command  that  the  target  has  been  destroyed, 
suppressed,  or  where  additional  fire  should  be  delivered. 

Purpose: 

Inform  the  commanders  on  effectiveness  of  delivered  rounds. 

Potential 

Problems: 

•  Range  limitations  force  this  step  in  the  communication  process. 

•  This  slows  down  the  speed  of  the  CEE. 

HSI 

Recommended 

Recommended  Eormat 

Recommended  System 

Co  EST:  Voice 

PET  CDR:  Voice 

AN/PRC- 1 17E  (SATCOM) 
AN/PRC- 150 
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10.1  Issue  a  Warning  Order 

Goal:  A  Warning  Order  is  issued  to  allow  a  unit  to  prepare  for  an  upeoming 
order. 

Description:  A  warning  order  is  issued  to  provide  a  unit  to  time  to  prepare  for  an 
upeoming  order.  It  should  eontain  as  much  information  as  is  available  at  the  time 
and  follow  the  5  paragraph  SMEAC  format  as  closely  as  possible. 

Communication: 


Sender:  Receiver:  Monitor:  Network: 

Potential 

Exchanges: 

CO  Co  PETCDR  Other  PET  CDRs  Company  Net 

Information 

There  is  no  official  format  for  warning  orders.  It  may  include 
elements  of  a  SMEAC  or  may  simply  instruct  a  unit  to  prepare  to 
move  out. 

Purpose: 

Provide  a  “heads  up”  to  lower  levels  of  command  that  an  order  will 
be  coming  down  the  chain. 

Potential 

Problems: 

Range  limitations. 

HSI 

Recommended 

Recommended  Eormat 

Recommended  System 

Co  EST:  Visual  /  Graphical 

AN/PRC- 150  w/  D-D  ACT 

11.1  Battalion  Issues  OPORD 

Goal:  Company  Commander  Receives  the  Operation  Order  from  the  Battalion 
Description:  The  Operations  Order  (OPORD)  it  usually  follows  the  5  paragraph 
SMEAC  format.  It  sets  forth  the  Situation,  the  Mission,  the  plan  and  method  of 
Execution,  Administration  and  Eogistics,  and  Command  and  Signal 
information. 

Communication: 


Sender: 

Receiver: 

Monitor: 

Network: 

Potential 

Exchanges: 

Battalio 

nCDR 

Co  CO 

Other  Co  COs 

Battalion  Net 

Information 

Provide  information  on  the  mission  objective  and  the  commander’s 
intent,  but  allowing  flexibility  on  how  the  mission  will  be  carried 
out.  Ideally  this  should  contain  all  5  elements  of  SMEAC. 
Situation  (enemy  and  friendly  forces).  Mission,  Execution 
(Commander’s  intent,  concept  of  operation,  etc), 

Administrative/Eogistics,  Command/Signal.  The  OPORD  is  a  more 
formal  document  and  may  be  distributed  in  a  digital  format. 

Purpose: 

Provide  an  overall  objective  to  the  Marine  unit  without  necessarily 
forcing  a  specific  solution. 

Potential 

Problems: 

No  identified  problems 

HSI 

Recommended 

Recommended  Eormat 

Recommended  System 

Co  CO:  Visual  /  Graphical 

AN/PRC- 1 17E  (SATCOM) 
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13,1,2  Request  Supplies  from  Combat  Supporting  Supply  (CSS) 

Goal:  Acquire  supplies  from  the  Battalion’s  Combat  Supporting  Supply 
Description:  Self  explanatory 

Communication: 


Sender:  Receiver:  Monitor:  Network: 

Potential 

Exehanges: 

Co  CO  CSS 

Battalion  Net 

Information 

Unit  Identification,  location,  types  of  supplies  needed,  urgency  of 
request. 

Purpose: 

Acquire  supplies  from  the  Battalion’s  Combat  Supporting  Supply 

Potential 

Problems: 

No  identified  problems 

HSI 

Recommended  Format 

Recommended  System 

Recommended 

Co  CO:  Visual  /  Graphical 

AN/PRC-1 17F  (SATCOM) 

13,2,1  Casualty  Report  (CASREP) 

Goal:  Inform  commanding  unit  on  wounded. 
Description:  Self  explanatory 

Communication: 


Sender:  Receiver:  Monitor:  Network: 

Potential 

Exchanges: 

PFTCDR  CO  Co  Other  PET  CDRs  Company  Net 

Co  CO  BN  CDR  Other  Co  Cos  Battalion  Net 

Information 

Number  of  casualties,  types  of  injuries,  urgeney  of  request. 

Purpose: 

Inform  command  unit  on  injuries.  Determine  the  appropriate 
course  of  action  for  handling  wounded. 

Potential 

Problems: 

No  identified  problems 

HSI 

Recommended 

Recommended  Format 

Recommended  System 

Co  CO:  Voice 

AN/PRC- 1 17F  (SATCOM) 
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13.2,2  Request  Casualty  Evacuation  (CASEVAC)  from  Battalion 

Goal:  Have  a  serious  easualty  moved  from  the  battlefield  for  immediate  eare. 
Description:  Self  explanatory 

Communication: 


Sender: 

Receiver: 

Monitor: 

Network: 

Potential 

Exchanges: 

SQD  EDR 

Battalion 

PET  CDR,  Co  CO 

PET  CDR 

Battalion 

Co  CO 

Co  CO 

Battalion 

Information 

Number  of  casualties,  types  of  injuries,  urgency  of  request. 

Purpose: 

Inform  command  unit  on  injuries.  Request  immediate  extraction  of 
critically  wounded  marines. 

Potential 

Problems: 

Range  limitations. 

Questions 

What  radio  would  be  used? 

HSI 

Recommended 

Recommended  Eormat 

Recommended  System 

? 

? 

13,2,3  Battalion  Responds  to  CASEVAC  Request  and  Provides  Contact  Information 
Goals:  Provide  information  to  CASEVAC  requester  on  how  CASEVAC  will 
oeeur. 

Description:  Self  explanatory 

Communication: 


Sender: 

Receiver: 

Monitor: 

Network: 

Potential 

Exchanges: 

Battalion 

SQD  EDR 

PET  CDR,  Co  CO 

?? 

Battalion 

PET  CDR 

Co  CO 

Battalion 

Co  CO 

Information 

Type  of  CASEVAC  asset  that  is  inbound,  how  to  contact  asset, 
when  asset  will  arrive. 

Purpose: 

Provide  information  to  CASEVAC  requestor  on  how  CASEVAC 
will  occur. 

Potential 

Problems: 

No  identified  problems 

HSI 

Recommended 

Recommended  Eormat 

Recommended  System 

? 

? 

35 


SOFTWARE  APPLICATIONS 


The  MCWL  concept  of  employment  for  the  Company  Level  Operations 
Center  details  several  software  applications  to  be  made  available  for  CLOC  personnel  to 
pass  lERs  via  electronic  means  (e.g.,  e-mail  attachments,  live  chat,  etc.)  vice  traditional 
voice  reports  sent  via  portable  radios.  The  paragraphs  to  follow  provide  detail  regarding 
applications  included  at  each  CLOC  work  station. 

COMMAND  AND  CONTROL  PERSONAL  COMPUTER  (C2PC) 

Intelligence  Operations  Workstations  (10 Ws)  are  the  equipment  suite, 
which  provide  automated  support  to  the  CLOC  via  the  C2  application  called  C2PC.  An 
lOW  is  simply  a  laptop  inside  the  CLOC,  which  is  pre-loaded  with  C2PC  and  many  other 
software  applications.  C2PC  provides  map  overlays,  friendly  unit  locations  with  status 
and  plans  of  intended  movement,  and  hostile  unit  locations.  C2PC  is  linked  together 
within  the  CLOC  via  a  Local  Area  Network  (LAN)  allowing  rapid  information  exchange 
between  staff  sections,  and  they  are  also  linked  with  adjacent,  subordinate,  and  higher 
headquarters  via  a  Wide  Area  Network  (WAN).  Using  the  Intelligence  Operations  Server 
(lOS),  C2PC  also  links  with  the  Intelligence  Analysis  System  (IAS)  for  the  reception  of 
intelligence  information  and  may  be  linked  with  the  Enhanced  Position  Eocation  and 
Reporting  System  (EPERS)  network  (if  used).  C2PC  provides  an  automated  message 
generation  and  validation  capability  for  the  exchange  of  MTE  messages  and  a  capability 
to  generate  and  validate  Variable  Message  Eormat  (VME)  messages.  C2PC  has  multiple 
injectors  that  allow  modular  systems  with  an  interface  with  other  capabilities  such  as 
AEATDS  through  the  Effects  Management  Tool  (EMT). 

C2PC  Capabilities: 

•  Eacilitates  C2  functions 

•  Displays  the  CTP 

•  Simultaneously  displays  multiple,  independent  map  windows 

•  Capable  of  displaying  multiple  areas  of  interest 

•  Supports  over  200  different  mapping  datum 
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•  Allows  users  to  display  mapping  features  ineluding  politieal  boundaries, 
rivers,  and  major  roadways 

FORCE  XXI  BATTLE  COMMAND  BRIGADE  AND  BELOW  -  BLUE 
FORCE  TRACKER  (FBCB2-BFT) 

Foree  XXI  Battle  Command  Brigade  and  Below  (FBCB2)  -  Blue  Foree 
Traeker  (BFT)  is  a  battle  eommand  information  system  designed  for  units  performing 
missions  at  the  taetieal  level.  FBCB2-BFT  displays  the  relevant  SA  pieture  of  the 
battlefield.  SA  shows  the  user  his  loeation,  the  loeation  of  other  friendly  forees,  observed 
enemy  loeations,  and  all  known  battlefield  obstaeles.  FBCB2-BFT  will  be  employed  by 
the  regimental  CLOC,  battalion  CLOC,  eaeh  eompany  CLOC,  and  eonvoys  and/or 
patrols  traversing  throughout  the  area  of  operations  (AO).  A  signifieant  advantage  of 
FBCB2-BFT  is  that  the  information  is  passed  via  L-Band  satellite.  This  means  that  it  is 
not  limited  to  Line-of-Sight  (LOS)  oharaoteristies  of  the  EPLRS  network. 

FBCB2-BFT  Capabilities 

•  Automated  Positional  Reporting 

•  Displays  Maneuver  Graphies 

•  Free  text  and  formatted  messaging  eapability 

•  Over  the  Horizon  (OTH)  oommunioations 

•  Message  Transmitter  providing  ID,  GPS  loeation.  Course,  and  Speed 

BIOMETRIC  A  UTOMA  TED  TOOLSET  (BA  T) 

BAT  provides  a  means  of  identifying  people  via  fingerprint,  iris  sean,  and 

photo  identifieation  (ID),  whieh  enables  the  ereation  of  individual  reeords.  The  system 

ineludes  a  laptop  with  the  BAT  software,  a  fingerprint  seanner,  an  iris  seanner,  a  digital 

eamera,  and  an  ID  eard  printer.  ID  badges  ean  be  provided  to  residents  of  a  eity  or  other 

identified  geographie  area.  By  eontrolling  the  routes  in  and  out  of  eities  via  Entry  Control 

Points  (ECPs),  and  only  providing  positively  identified  residents  with  badges,  it  ereates 

an  obstaele  to  others  posing  as  residents.  Using  iris  seans  or  fingerprints.  Marines  at 

ECPs  ean  verify  identity  via  eonneetivity  to  the  shared  reeords  database.  The  Marine  ean 
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access  information  such  as  the  person’s  birth  date,  oeeupation,  plaee  of  residenee,  and 
any  doeumentation  addressing  affiliation  with  anyone  involved  in  terrorist  aetivities. 

BAT  Capabilities: 

•  Efficiently  enroll,  verily,  and  identify  individuals  eneountered  in  the 
eonduct  of  operations 

•  Rapidly  eompare  identity  information  to  wateh  lists. 

•  Rapidly  record  various  types  of  information  assoeiated  with  an 

individual 

•  Rapidly  reeall,  update,  and  manage  ‘trusted’  information  assoeiated  with 

individuals 

•  Rapidly  assess  credibility  of  a  witness 

•  Operates  remotely/non- intrusively  against  non-eooperative  subjeets 

MARINELINK 

MarineLink  is  designed  to  allow  analysts  to  mine  internal  and  external 
data  sourees,  visually  display  the  data  on  a  map,  store  the  data  loeally,  and  generate 
produets  and  reports  to  help  disseminate  the  information  and  intelligenee.  This  program 
is  provided  as  part  of  the  Intelligenee  Analysis  System  (IAS)  software  paekage  that  is  on 
all  10 W  eomputers. 

Importance  of  MarineLink  to  the  CLOC 

Using  MarineLink,  users  ean  visualize  data  within  the  map  viewer,  filter 
or  sort  results,  generate  graphs,  eopy  data  from  an  external  data  source  to  Intel  Traeker, 
and  eopy  data  into  Report  Builder.  It  allows  users  to  quickly  search,  sort,  build  graphs 
and  reports,  and  provides  information  in  a  usable  format.  MarineLink  reduees  the  amount 
of  time  required  to  do  these  tasks. 

Sources  that  MarineLink  Can  Query 

MarineLink  supports  data  mining,  pattern  analysis,  and  trends  and  taetics 
analysis.  It  provides  the  ability  to  query  the  following  data  sourees: 

38 


•  All  Source  Analysis  System-Light  (ASAS-L)  -  Army  S-2 

•  Analyst  Notebook  (Link  Analysis  Charts) 

•  BAT  and  HIIDE  systems  (Biometric  Databases) 

•  C2PC  overlays  and  traeks  (C2PC  6.1.1  required) 

•  Digital  Aeronautieal  Flight  Information  File  (DAFIF) 

•  Google  Desktop  (Doeuments/email  stored  on  your  eomputer) 

•  Gazetteer  (Geographie  plaee-names  if  the  world) 

•  Imagery  Product  Fibrary  (IPF)  (National,  Theater  and  MFF-level  Geo- 
rectified  imagery) 

•  Intel  Traeker  (as  available  from  unit  and  external  sourees) 

•  Foeal  Map  Server  (Raster,  CIB,  DTED  maps) 

•  Modernized  Integrated  Database  (MIDB)  (DIA  database  of  worldwide 
General  Military  Intelligenee) 

c.  Experiment  Metrics 

The  IX  Chariot  software  used  in  this  experiment  makes  three  basic  types 
of  measurements  that  are  useful  when  determining  network  performanee.  The 
measurements  inelude  throughput,  transaetion  rate,  and  response  time.  For  this 
experiment  the  software  was  installed  on  one  of  the  nodes  at  the  CLOC;  this  laptop 
served  as  the  “eonsole,”  whieh  sends  scripts  to  “endpoints”  and  also  colleets  polling  data 
sent  from  the  endpoints.  In  this  partieular  FOF  only  two  endpoints  were  established, 
although  the  user’s  manual  states  the  software  ean  manage  thousands  of  endpoints  whieh 
will  simulate  very  large  networks.  See  Appendix  B  for  a  more  detailed  explanation  of  the 
software.  The  following  paragraphs  define,  aeeording  to  the  IX  Chariot  user’s  manual, 
how  the  software  ealculates  each  of  the  metries. 
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Throughput  is  defined  as  the  “amount  of  data  that  a  medium  ean  transmit 
during  a  given  period  of  time.”  ix  Chariot  calculates  throughput  for  a  pair  of 
endpoints  in  a  non-streaming  script  using  the  following  equation: 

(Bytes _Sent+ Bytes  Received  By  Endpoint _1)  /  Throughput _Units)  / Measured _Time^^ 

The  transaction  rate  is  the  number  of  script  transactions  that  are  executed 
per  second.  What  defines  a  transaction  depends  on  the  particular  script.  In  general  a 
single  transaction  is  one  loop  through  a  particular  scripts  actions,  for  example,  in  a  file 
send  script  a  transaction  would  include  the  file  request,  the  acknowledgement  of  request, 
the  file  being  sent  and  the  acknowledgement  of  receipt.  Transaction  rate  is  calculated  by 
IX  Chariot  using  the  following  formula: 

Transaction  Count / Measured _Time^^ 

The  final  set  of  data  collected  during  the  experiment  was  response  time. 
The  response  time  is  the  inverse  of  the  transaction  rate.  The  calculations  are  shown  in 
seconds  per  transaction.  This  value  is  calculated  as  follows: 

MeasuredJTime  /  Transaction  Count^^ 

d.  Experiment  Scripts 

During  this  LOE,  fourteen  IX  Chariot®  default  scripts  were  run  as  well  as 
two  tests  that  involved  the  actual  collaborative  software  applications,  mIRC  Chat  and 
Microsoft’s  NetMeeting.  The  following  is  a  list  of  the  IX  Chariot®  scripts.  Unless 
otherwise  noted  each  script  was  run  between  one  pair  of  endpoints,  utilizing  the  Internet 
Protocol  (IP)  core  protocol.  Transmission  Control  Protocol  (TCP).  All  script  descriptions 
are  excerpted  from  the  IX  Chariot®  Scripts  and  Streams  Library  Reference,  release  6.50, 
Revision  A,  2007. 


13  Tamara  Dean,  Network+  Guide  to  Networks  (Massachusetts:  Course  Technology, 2006),  144. 

IX  Chariot  User  Guide,  CD-ROM  Release  6.50,  IXIA,  2007. 

15  Ibid. 

15  Ibid. 
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1.  Throughput.scr:  In  Throughput.scr,  Endpoint  1  sends  a  100,000  byte  fde  to 

Endpoint  2.  Endpoint  2  sends  an  acknowledgment  upon  receipt  of  the  file. 

2.  Throughput.scr:  Same  as  above  utilizing  Eiser  Datagram  Protocol  (EiDP). 

3.  Responsetime. scr:  This  script  tests  network  response  time.  Endpoint  1  sends  a 

100-byte  file;  Endpoint  2  receives  it  and  sends  an  acknowledgment. 

4.  Responsetime. scr:  Same  as  above  utilizing  UDP. 

5.  Eilesndl.scr:  Eile  Send,  Eong  Connection.  Endpoint  1  requests  and  receives  a  fde; 

Endpoint  2  sends  the  requested  file  and  receives  an  acknowledgement.  One 
connection  is  made  for  the  entire  transaction. 

6.  Eilercvl.scr:  Eile  Receive,  Eong  Connection.  The  pair  script  to  Eile  Send.  Two 

endpoints  interact  to  send  and  receive  a  100,000  byte  file.  The  request  and 
acknowledgement  default  to  100  bytes. 

7.  DBaseE.scr:  Database  Update,  Eong  Connection.  The  database  update  scripts  are 

the  most  complex  of  the  benchmarks.  These  scripts  emulate  a  program  that 
requests  a  record  from  Endpoint  2,  receives  it,  updates  it,  and  sends  it  back. 
East,  Endpoint  1  receives  a  confirmation  that  the  update  was  completed.  All 
file  sizes  default  to  100  bytes. 

8.  SMTP  Payload.scr:  The  SMTP  Payload.scr  script  emulates  the  sending  of  one  or 

more  email  messages  over  a  TCP  network.  The  default  size  of  an  email 
message  is  1,000  bytes,  with  an  additional  20-byte  header.  In  addition  to  a 
login/logout  sequence,  payload  data  is  included  for  an  email  containing  an 
IxChariot  newsletter  notice. 

9.  activePTPget  Payload.scr:  This  script  emulate  sending  a  file  from  Endpoint  1, 

using  active-mode  ETP.  Only  the  data  channel  is  emulated,  and  an  active 
(versus  passive)  connection  is  used.  The  script  emulates  the  transfer  of  an 
IxChariot  newsletter  file.  The  activeETPget_Payload  script  is  designed  to 
emulate  the  actual  file  transfer  portion  of  an  ETP  transaction. 
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10.  HTTPText  Payload. scr:  These  seripts  emulate  the  transfer  of  graphics  and  text 

files  from  an  HTTP  server  for  the  Web  page: 
http://www.ixiacom.com/about_us/.  The  actual  request  and  data  are  enclosed 
in  embedded  payloads. 

1 1 .  ICQ  Text  Chat.scr:  The  text  chat  scripts  emulate  an  IRC  client  sending  the  word 

Hello  to  a  receiving  IRC  client  on  his  buddy  list.  The  receiving  IRC  client 
responds  with  the  words  Hello  back.  A  number  of  IRC  Text  chat  scripts  (for 
example,  Microsoft)  include  a  more  explicit  client  authentication  and  join 
process  between  the  two  clients  prior  to  the  message  exchange.  All  scripts 
include  a  separate  loop  to  allow  the  user  to  determine  the  exact  count  of 
messages  that  are  being  exchanged.  The  default  number  of  messages  is  set  to 
ten  (10)  per  transaction.  In  addition,  prior  and  post  any  message  send  requests, 
SLEEP  commands  have  been  added  to  the  script  to  simulate  the  users  either 
typing  or  reading  the  message.  The  default  setting  for  each  SEEEP  is  zero 
seconds. 

12.  Netmtgv.scr:  These  script  emulate  sending  video  streams,  using  Microsoft 

NetMeeting  v2.1  over  a  100  Mbps  Ethernet  LAN.  Along  with  the  audio  or 
video  traffic,  a  small  amount  of  control  traffic  is  exchanged  between  the 
participating  computers  using  a  different  port  number  pair.  The  control  traffic 
is  not  emulated  in  these  scripts.  The  send_data_rate  is  set  to  64  kbps.  The 
type  value  for  the  RTP  PAYLOAD  TYPE  is  set  to  H261  for  H.26L 

13.  HTTP  Streaming. iag:  This  application  group  uses  two  pairs  to  emulate  an  HTTP 

session  with  streaming  video  data.  The  HTTP  session  involves  these  tasks: 

1.  Browse  to  a  Web  page  containing  a  video  link. 

2.  Select  the  video  link. 

3.  View  the  video  in  the  player  that  is  automatically  opened  when  the  link 
is  selected. 

The  first  pair  provides  the  Control  connection,  via  the 
HTTP  streaming  control.scr  script.  The  control  connection  is  a  TCP 
connection  that  emulates  browsing  to  a  Web  page  and  clicking  on  a  video 
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link.  The  second  pair  provides  the  Data  connection,  via  the 
HTTPstreamingdata.scr  script.  This  connection  emulates  the  video 
streaming  from  the  Web  server  to  the  user's  desktop. 

14.  active  FTP.iag:  This  application  group  uses  two  pairs  to  emulate  the  two 
connections  needed  to  accomplish  an  active  FTP  operation.  In  active  mode 
FTP,  the  client  connects  from  a  random  unprivileged  port  (the  port  number  is 
higher  than  1,024)  to  the  FTP  server's  command  port  (port  21).  Then,  the 
client  starts  listening  to  port  N+1  and  sends  the  FTP  command  PORT  N+1  to 
the  FTP  server.  The  server  then  connects  back  to  the  client's  specified  data 
port  from  its  local  data  port  (port  20).  The  first  pair  provides  the  Control 
connection,  via  the  active  FTP  control.scr  script.  The  second  pair  provides 
the  Data  connection,  via  the  active  FTP  data.scr  script. 

e.  Impact  of  Concurrent  Experiment 

As  mentioned  earlier,  another  Master’s  degree  candidate  was  running, 
concurrent  with  this  LOE,  an  experiment  on  the  feasibility  of  network  management  using 
SNMP  in  an  effort  to  determine  if  a  SATCOM  type  network  could  be  managed  from 
higher  headquarters  in  an  effort  to  ease  the  manpower  and  training  impact  adoption  of 
SATCOM  technology  at  a  company  level  would  incur.  The  SNMP  console  was  running 
the  commercial  software  SolarWinds  Engineering  Edition  as  the  network  management 
application,  and  was  responsible  for  collecting  data  on  network  performance  and  was  the 
originator  of  network  management-related  tasks.  In  addition  to  running  SolarWinds,  the 
management  host  was  also  running  the  traffic  analyzer  Wireshark,  which  was  used  to 
capture  packets  traversing  from  the  management  agent  to  the  rest  of  the  network.  In 
addition  to  the  transfer  of  the  IX  Chariot®  Scripts  across  the  network,  the  management 
agent  set  a  polling  interval  for  SNMP  data  at  120  to  240  seconds.  The  SNMP  data  sent 
over  the  network  included  User  Data  Protocol  (UDP)  datagrams  which  contained  the 
polling  data  and  the  Internet  Control  Message  Protocol  (ICMP)  messages  encapsulated 
within  an  Internet  Protocol  (IP)  datagram.  SNMP  is  typically  a  64  bit  datagram,  while 
ICMP,  a  Network  layer  protocol  that  indicates  data  delivery  success  or  failure,  can  range 
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between  576  bytes  to  65  kilobytes.!^  Although  the  overhead  assoeiated  with  remote 
network  management  will  deerease  the  overall  bandwidth  available  to  pass  lERs  and 
should  always  be  eonsidered  when  testing  a  new  material  solution  for  networked 
eommunieation,  the  SNMP  traffic  across  the  network  was  consistent  for  each  of  the 
scripts  run  during  this  LOE,  and  therefore  overhead  will  become  transparent  in  a 
comparison  of  the  different  types  of  lER  scripts. 

B,  EXPERIMENT  UTILITY 

The  EOE  for  this  thesis  was  scheduled  to  take  place  from  0800  on  Monday, 
August  4,  2008  through  1600  on  Thursday,  August  7,  2008.  Day  one  (Monday)  was  to 
include  a  half  day  of  set-up  with  baseline  testing  to  begin  in  the  afternoon.  The 
remaining  days  were  to  be  used  to  test  an  incremental  increase  in  the  number  of  scenario 
scripts  passed  across  the  network.  Encryption  would  be  applied,  and  the  same  tests  run 
again.  However,  due  to  issues  with  the  software  operating  system  on  one  of  the  Swe- 
Dish  IPTs,  it  took  three  days,  with  extensive  phone  support  from  a  Swe-Dish  technical 
representative  to  establish  the  satellite  connection.  This  setback  left  only  Thursday  for 
actual  testing.  With  one  day  to  gather  data  on  test  scripts  that  at  times  took  upwards  of 
four  hours  to  run  to  completion  only  the  most  basic  testing  was  completed.  Eor  purposes 
other  than  base  lining  one  particular  small  aperture  satellite  configuration  all  but  two  of 
the  tests  provide  no  utility  in  determining  whether  or  not  SATCOM  is  a  viable  solution  to 
meet  the  lERs  at  CEOC.  Those  two  tests,  where  mIRC  Chat  and  NetMeeting  were  used, 
each  provided  data  demonstrating  that  a  specific  disadvantaged  terminal  can  support 
multiple  types  of  traffic  broadcast  over  the  network  at  the  same  time  using  actual 
applications  installed  on  the  operating  workstations.  Another  shortcoming  induced  by  the 
equipment  malfunction  and  subsequent  decreased  timeline  include  the  lack  of  any 
measurements  on  the  effects  encryption  would  have  had  on  the  performance  of  the 
network  in  supporting  the  exchange  requirements. 

Given  the  previously  mentioned  lack  of  a  standard  list  of  lERs  for  units  smaller 
than  a  battalion,  it  was  determined  that  even  if  the  experiment  had  been  executed 

Tamara  Dean,  Network+  Guide  to  Networks  (Massachusetts:  Course  Technology,  2006). 
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according  to  plan  that  particular  set  of  data  would  only  have  been  representative  at  most 
of  one  partieular  battalion’s  opinion  of  what  exchanges  should  be  measured.  Such  data, 
measured  for  utility  aeross  infantry  companies  throughout  the  Marine  Corps,  is  as  useful 
as  no  data.  While  the  LOE  failed  to  provide  the  data  neeessary  to  meet  the  primary  thesis 
objeetive  the  proeess  of  researehing  a  validated  list  of  lERs  provided  a  mueh  better 
understanding  regarding  how  similar  experiments  should  be  eondueted  in  the  future.  The 
data  gathered  during  one  day  of  testing  is  provided  in  the  next  ehapter,  ineluding  an  in 
depth  analysis  of  the  last  test  seenario,  while  the  remaining  portions  of  the  thesis  will 
emphasize  those  actions  required  to  make  similar  testing  valuable  to  the  designers  of 
future  communieation  networks  utilizing  SATCOM. 

Although  the  IPX  malfunetion  deereased  the  utility  of  this  EOE  as  a  tool  for  future 
Marine  Corps  oommunieations  arehiteets  detailing  possible  solutions  for  an  Enhaneed 
Company,  the  reader  should  note  that  the  Swe-Dish  terminals  employed  in  this 
experiment  have  sueeessfully  been  used  as  a  means  to  pass  eomparable  information 
exchanges  in  other  experiments  run  by  the  Naval  Postgraduate  SehooTs  CENETIX 
Eaboratory.  The  authors  have  personally  used  the  equipment  in  a  number  of  the  lab’s 
Tactieal  Network  Topology  (TNT)  series  of  experiments,  whose  objeetive  is  the  study  of 
’’multiplatform  taetieal  networks.  Global  Information  Grid  eonneetivity,  eollaborative 
teehnologies,  situational  awareness  systems,  multi-agent  arehiteetures,  and  management 
of  sensor-unmanned  vehiele-decision  maker  self-organizing  environments.”^^  The  TNT 
experiments  have  previously  focused  on  the  use  of  the  802.16  wireless  standard  and 
traditional  RE  radio  teehnology  during  seenarios  that  inelude  the  passing  of  biometrie 
data  between  deployed  forees  and  a  loeal  operations  eenter  as  well  as  the  maritime 
interdietion  of  possible  Weapons  of  Mass  Destruetion  (WMD)  material.  The  seenarios 
first  ineorporated  SATCOM  as  a  baekup  link  to  the  primary  wireless  link.  During  several 
experiments  the  wireless  link  did  indeed  fail  and  the  Swe-Dish  terminal  provided  a 
backup  capability  that  proved  transparent  to  the  users;  allowing  eaeh  node  to  seamlessly 
eontinue  the  same  information  exehanges  and  use  the  same  situational  awareness 

“Center  for  Network  Innovation  and  Experimentation,”  Center  for  Network  Innovation  and 
Experimentation,  http://cenetix.nps.edu/cenetix/  (accessed  September  15,  2008). 
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building  software  applications  as  before  the  failure  with  no  noted  degradation  in  service. 
Recently,  the  TNT  experiments  have  begun  to  include  point  to  point  configurations  using 
the  Swe-Dish  terminals  to  successfully  connect  nodes  in  several  states  as  well  as  nodes  as 
far  away  as  Europe. 
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IV.  RESULTS 


A.  ANALYSIS  OF  DATA 

To  understand  the  data  eolleeted  during  the  LOE,  the  relationship  between  data 
rate,  antenna  size,  and  transmitter  power  must  first  be  defined.  When  eommunieation 
arehiteets  set  out  to  design  a  SATCOM  network  they  size  the  link  using  the  link  equation 
or  link  budget.  This  equation,  shown  below,  relates  all  the  parameters  of  a  SATCOM 
“link”  needed  to  eompute  the  signal-to-noise  ratio  of  the  eonneetion.i^ 

E,  _  PL, 0,13136, 

No  kT^R 

Eb/No  is  the  ratio  of  reeeived  energy-per-bit  to  the  noise  density;  for  a  system  to  be 
able  to  pick  the  intended  signal  out  of  the  noise  associated  with  the  connection  the  ratio 
must  be  higher  than  1.  Typically  an  Eb/No  ratio  between  5  and  10  is  adequate  for  digital 
communications  with  low  probability  of  error.20  P  represents  the  power  of  the 
transmitter.  Ei,  Eg,  La  are  various  losses,  or  reductions  in  power,  from  transmitter-to- 
antenna  line  loss,  space  loss  and  transmission  path  loss  respectively.  Gt  and  Gr  are  gain 
of  the  transmitter  and  receiver  respectively  (both  depend  on  the  diameter  of  the  dish  as 
well  as  frequency  broadcast),  k  is  Boltzmann’s  constant,  Tg  is  the  system  noise 
temperature  and  R  is  the  data  rate.  If  all  but  P,  R  and  Gt  were  held  constant  then  an 
increase  in  data  rate,  would  require  a  similar  increase  in  the  power  of  the  transmitter,  the 
gain  of  the  transmitter,  or  both.  Current  fielded  small  aperture  SATCOM  technology, 
due  to  requirements  for  portability  and  compactness,  are  necessarily  limited  in  both 
power  and  transmit  antenna  gain.  Therefore,  data  rates  for  users  of  such  technology  are 
similarly  restricted.  In  this  LOE,  both  the  uplink  and  downlink  were  leased  at  1  Mbps 
data  rates,  however,  the  data  collected  in  this  experiment  shows  that  the  base  line  raw 
data  rate  was  570  Kbps,  emphasizing  the  disadvantaged  nature  of  the  tested  equipment. 


Wiley  Larson  and  James  Wertz  (eds.),  Space  Mission  Analysis  and  Design,  (New  York,  NY : 
Springer- Verlag  New  York  LLC,  1992),  520. 

20  Ibid. 
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A  point  to  consider  when  examining  the  data  is  the  fact  that  IX  Chariot®  measures 
only  the  throughput  assoeiated  with  the  Internet  Protoeol  (IP)  packet  payload  and 
disregarding  the  198  bit  IP  headers  associated  with  the  traffic.  Therefore  the  data 
represents  throughput  that  is  actually  less  than  what  was  actually  passed  over  the 
network. 

Also,  keep  in  mind  that  while  the  IX  Chariot®  test  scripts  were  being  executed,  a 
small  amount  of  network  management  traffic  was  simultaneously  injected  into  the 
network  whieh  subsequently  reduced  the  bandwidth  available  for  data  generated  by  the 
test  seripts.  However,  sinee  the  SNMP  traffie  was  running  at  a  set  interval  for  all  tests  its 
effeet  was  constant  for  all  the  scripts  it  could  be  eonsidered  insignifieant  for  comparisons 
of  two  or  more  types  of  test  seripts. 

Table  2  shows  the  average  throughput,  transaction  rate  and  response  time  from 
the  IX  Chariot®  test  console  for  all  tests  except  the  final  two  which  utilized  actual 
software  applications  previously  loaded  onto  workstations  at  both  the  battalion  and 
company  nodes.  A  separate  application,  Wireshark,  was  used  to  capture  the  data  for  the 
mIRC  and  NetMeeting  based  exehanges. 

The  first  two  tests  were  run  to  determine  the  baseline  eapability  of  the  tested 
network  eonfiguration.  The  response  time  results  coneur  with  expected  response  times 
for  a  transmission  link  with  a  geostationary  communications  satellite.  For  the  purpose  of 
this  LOE,  a  non-streaming  script  is  one  that  requires  two  way  communication  while 
streaming  seripts  require  one-way  flow  at  a  specifie  data  rate. 21 


21 IX  Chariot®  Scripts  Development  and  Editing  Guide,  CD-ROM  Release  6.50,  Version  1.9,  IXIA, 
2008. 
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SCRIPT 

THROUGHPUT 

AVG.  (Mbps) 

TRANSACTION  RATE 

AVG.  (#/sec.) 

Throughput' 

0.570 

0.715 

1.398 

Response  time' 

0.003 

1.971 

0.507 

File  Send  Long' 

0.586 

0.735 

1.361 

File  Rec.  Long' 

0.587 

0.736 

1.359 

Data  Base' 

0.002 

0.986 

1.014 

SMTP  Payload' 

0.012 

0.237 

4.225 

FTP  Get  (Active)  * 

0.033 

0.826 

1.211 

http  Payload' 

0.108 

1.427 

0.701 

ICQ  Text  Chat' 

0.016 

0.143 

7.001 

NetMeeting  (Video)^ 

0.064 

Not  measured 

Not  measured 

HTTP  Streaming^ 

0.876 

1.974 

22.889 

Active  ftp' 

0.093 

1.037 

2.365 

mlRC  (Actual)^’^ 

0.400 

Not  measured 

0.510 

NetMeeting  (Actual)^’^ 

0.400 

Not  measured 

0.510 

1  -  Non-streaming  script 

2  -  Streaming  script 

3  -  Data  pulled  from  Solar  Winds  software  program  vice  IX  Chariot® 

Table  2.  Summary  of  LOE  Data 


The  final  test  set,  using  NetMeeting,  was  the  most  comprehensive,  and  was 
originally  developed  to  stress  the  satellite  link.  This  particular  test  consisted  of  multiple 
NetMeeting  protocols  being  transferred  simultaneously,  specifically  a  video  and  text  chat 
session,  a  file  transfer,  and  an  application  share,  where  the  receiving  node  of  the 
exchange  has  access  to  the  sender’s  desktop  applications.  Microsoft’s  TechNet  website, 
explains  that  NetMeeting  utilizes  both  the  TCP  standard  for  data  transport  and  call 
control,  and  the  UDP  standard  for  secondary  connections  for  sending  and  receiving  audio 
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and  video .22  As  with  the  previous  test  sets,  the  presence  of  the  ICMP  and  SNMP 
management  data  is  purposely  injected  by  the  network  management  agent.  Comparing 
this  last  sample  with  the  previous,  there  is  a  marked  increase  in  the  receive/transmit 
kilobits  per  second  (Kbps)  on  each  of  the  two  nodes.  Figure  3  shows  throughput  at  levels 
almost  the  advertised  data  rate  of  the  leased  satellite  channels. 


Figure  3.  Portion  of  screen  shot  from  NetMeeting  test 


22  “NetMeeting  3.0  Resouree  Kit,”  Microsoft  Tech  Net,  http://technet.microsoft.com/en- 
us/library/cc767134.aspx  (accessed  September  8,  2008). 
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B,  COMPARISON  OF  TESTED  SCRIPTS  TO  SOFTWARE  IN  MCTOG 

CLOC  CONCEPT  APPLICATIONS 

Table  3  maps  the  IX  Chariot®  scripts  to  the  applicable  MCTOG  software 
requirements.  Development  of  this  table  was  difficult  due  to  lack  of  information  on  the 
majority  of  the  MCTOG  software.  Repeated  attempts  to  gain  detailed  information 
(packet  sizes,  protocols  used,  and  frequency  of  exchanges)  were  hampered  because  most 
of  the  software  is  proprietary  and  vendors  were  not  forthcoming  with  the  information. 
Based  on  discussion  with  MCWL  representatives  and  Marines,  the  MCTOG  software 
was  mapped  back  to  the  IX  Chariot®  scripts  as  follows. 


MCTOG  Software 

MarincLink 

C2PC 

Filesndf  scr 

BAT 

FBCB2-BFT 

MarincLink 

C2PC 

Filercvl.scr 

BAT 

FBCB2-BFT 

MarincLink 

DBaseL.scr 

C2PC 

BAT 

SMTPPayload.  scr 

C2PC 

Email 

activcFTPget  Payload,  scr 

BAT 

HTTPText  Payload,  scr 

C2PC 

ICQ  Text  Chat,  scr 

mIRC 

Netmtgv.scr 

mIRC 

http  Streaming,  lag 

VTC 

C2PC 

active  FTP.iag 

BAT 

able  3.  Comparison  of  IX  Chariot®  Script  to  MCTOG  Software  Applications 
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V.  CONCLUSION  AND  RECOMMENDATIONS 


A.  WHAT  WAS  LEARNED 

The  main  objective  of  this  thesis  was  to  conduct  an  LOE  on  a  particular 
SATCOM  terminal  technology  against  a  standardized  list  of  small  unit  lERs.  However, 
through  research,  it  was  determined  that  no  such  list  existed  and  that  results  of 
experimentation  regarding  lERs  are  of  no  value  until  the  Marine  Corps  develops  a 
consistent  list  that  applies  to  company  and  below  sized  units.  Important  insight  to  the 
second  and  third  order  impacts  of  fielding  SATCOM  technology  at  the  less  than  battalion 
size  unit  will  help  expand  the  evaluation  metrics  of  future  EOEs  beyond  a  purely  data 
centric  measurement  set.  During  research  for  this  thesis,  the  authors  conversed  with 
many  stakeholders  regarding  the  exact  nature  of  which  information  exchange 
requirements  were  required  for  isolated  decision-making.  To  our  surprise,  although  there 
are  many  different  research  bodies  genuinely  interested  in  defining  lERs  for  company 
and  below  sized  units,  there  exists  no  definitive  sources  for  this  information  and  there  is  a 
noticeable  lack  of  coordination  between  the  various  efforts  to  determine  a  standardized 
list. 

Despite  the  previously  noted  shortcomings  of  the  limited  objective  experiment, 
the  authors  learned  a  tremendous  amount  regarding  the  minutiae  involved  in  finding  and 
evaluating  solutions  to  the  problem  of  providing  the  technical  support  needed  by  a  small 
unit  leader  to  make  decisions  in  an  isolated  environment.  Based  on  the  knowledge 
gained  over  the  past  months  the  authors  provide  the  following  recommendations 
regarding  the  objectives  of  this  thesis  as  well  as  some  strategic  recommendations  on  the 
subject  of  procuring  technical  solutions  in  support  of  information  exchange  requirements 
required  for  the  asymmetric  battlefield  of  today  and  the  future. 

B,  SATCOM  TERMINAL  RECOMMENDATION 

1,  Proof  of  Concept 

Although  only  supported  with  one  set  of  data  points,  the  results  of  the  final 

NetMeeting  test  script  serve  as  a  proof  of  concept  that  two  disadvantaged  terminals  were 
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capable  of  managing  an  sufficient  collection  of  simultaneously  transmitted  application 
protocols,  in  addition  to  network  management  related  data.  The  following  additions  to 
the  LOE  will  serve  to  improve  the  utility  of  the  experiment: 

•  To  provide  a  more  concrete  data,  a  similar  test  should  be  scheduled  with 
ample  time  to  run  test  scripts  in  their  entirety  as  well  testing  of  scenarios 
containing  multiple  application  protocols. 

•  The  test  should  include  or  simulate  the  exact  specifications  and  protocols  of 
the  determined  set  of  applications  that  will  support  the  isolated  decision 
maker. 

•  Due  to  the  nature  of  military  communications,  security  is  paramount. 
Therefore,  the  test  should  be  run  again  with  encryption  applied.  The  data 
derived  from  this  experiment  can  be  compared  to  the  unencrypted  data  set  to 
provide  knowledge  on  the  impact  of  encryption  on  required  bandwidth. 

•  Because  disadvantaged  users  are  physically  limited  to  data  rates, 
enhancements,  such  as  IP  accelerators  should  be  tested  as  a  method  of 
improving  the  capacity  of  such  networks. 

•  All  of  these  tests  should  only  be  conducted  after  a  line  item  list  of  lERs  and 
their  associated  applications  or  modes  of  transmittal  are  validated  by  the  user, 
namely  the  small  unit  leader. 

2,  Higher  Order  Impacts 

In  addition  to  the  purely  data  centric  metrics  above,  consideration  should  be  made 
regarding  the  impacts  of  fielding  new  equipment  will  have  on  manpower,  training, 
logistics  and  cost.  Laboratory  assumptions  should  be  confirmed  by  seeking  input  from 
the  warfighter  user.  Even  if  a  certain  technology  is  capable  of  providing  all  the  necessary 
bandwidth  required  for  the  appropriate  information  exchanges,  that  equipment  is  no  more 
than  ballast  if  it  can’t  be  transported  using  organic  assets,  can’t  be  run  without 
lightweight  power  sources  or  cannot  be  operated  with  a  minimum  amount  of  training. 
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This  experiment  is  a  perfeet  example  that  something  as  simple  as  equipment  set-up  can 
often  be  a  show  stopper  without  proper  technical  support  or  training. 


C.  BANDWIDTH  MANAGEMENT 

The  electro-magnetic  spectrum  is  a  finite  physical  resource;  it  can  only  be  divided 
and  sub-divided  to  a  certain  point.  Rather  than  continuing  attempts  to  divide  a  decreasing 
asset  among  ever-increasing  users,  efforts  should  be  made  to  develop  methods  of 
decreasing  demand  while  supplying  the  same  amount  of  utility. 

1.  Re-examine  “Network  Centric  Warfare”  Specifics 

Operational  View-Level  One  (OV-1)  diagrams  depicting  the  “Network  Centric” 
warfare  concept  are  very  appropriate  for  illustrating  the  level  of  connectivity  that  will  be 
required  to  successfully  wage  war  on  an  asymmetric  battlefield  and  gain  the  information 
advantage  over  any  adversary.  However,  the  lightning  bolts  that  connect  the  magnitude 
of  nodes  in  the  diagram  fail  to  quantify  exactly  what  tools  are  necessary  for  the  small  unit 
leader  and  tactical  level  warfighter  to  complete  their  mission  successfully.  Future 
network  architects  must  use  a  bottom  up  approach  to  design  allowing  them  to  focus  on 
information  the  tactical  unit  and  isolated  decision  maker  require  to  execute  its  mission; 
not  necessarily  what  would  increase  the  situational  awareness  of  higher  headquarters  or 
operational  and  strategic  level  decision  makers.  After  those  requirements  have  been 
defined  researchers  can  work  in  reverse  to  convert  lower  level  requirements  into  data  that 
is  useful  to  higher  level  units.  Rather  than  live  video  feed  from  a  helmet-mounted  camera 
to  indicate  enemy  contact,  could  an  application  be  developed  that  uses  voice  recognition 
to  convert  a  verbal  report  to  map  grids?  Will  a  low-resolution  snapshot  suffice  for 
positive  I.D.  instead  of  Unmanned  Aerial  Vehicle  (UAV)  feed?  Can  a  small  unit 
commander  act  as  a  “step  site“  for  his  Marines  to  gain  access  to  higher  level 
communication  services  thus  reducing  the  number  of  nodes  that  require  bandwidth  from  a 
dozen  to  one? 
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2,  Improved  Use  of  Bandwidth 

In  2004,  the  U.S.  Army  commissioned  Rand  Corporation  to  study  the  bandwidth 
requirements  of  its  forces.  In  the  report,  the  authors  stated  that  “New  Technologies  will 
greatly  increase  capacity,  but  unchecked  user  demands  will  probably  keep  pace  and 
exceed  available  capacities.  No  single  technique  will  solve  the  problem.  There  are  no 
silver  bullets. ”23 

The  report  is  an  excellent  source  of  methods  to  optimize  the  existing  bandwidth. 
The  report  was  conducted  for  the  U.S.  Army;  however,  the  concept  could  easily  be 
adapted  by  the  Marine  Corps.  Optimally,  a  similar  report  should  be  conducted  that 
analyzes  the  Marine  Corps  use  of  the  EM  spectrum  to  transmit  information.  At  a 
minimum,  this  report  should  be  used  as  a  reference  for  those  defining  Standard  Operating 
Procedures  (SOPs)  as  well  as  Tactics,  Techniques  and  Procedures  (TTPs)  for  future  small 
unit  operations  centers. 

D,  DEFINING  BANDWIDTH  REQUIREMENTS 

One  of  the  most  challenging  parts  of  the  thesis  was  attempting  to  define  the  lER 
set  required  by  a  company  commander  to  make  a  timely,  well-informed  decision  in  an 
isolated  environment.  Expectations  of  finding  a  subject  matter  expert  in  the  many  Marine 
Corps  agencies  dedicated  to  improving  Warfighting  capability  or  receiving  a  definitive 
answer  through  face-to-face  interviews  were  met  with  disappointment.  What  was 
discovered  were  various  uncoordinated  efforts  by  a  number  of  different  agencies  trying  to 
gather  the  same  information. 

To  address  this  situation.  Marine  Corps  Combat  Development  should  appoint  a 
single  entity  to  maintain  oversight  on  efforts  to  define  a  list  of  lERs  for  units  below 
battalion  size.  Two  candidates  exist  for  this  position;  MCCDC’s  Command  and  Control 
Integration  Division  (C2ID)  based  on  their  efforts  in  defining  the  Capability  Sets 
(CAPESETs)  1-4  for  the  Combat  Operations  Center  and  the  newly  formed  Marine  Corps 


23  Leland  Joe  and  Isaac  Porche  III,  Future  Army  Bandwidth  and  Capabilities  (Santa  Monica,  CA: 
Rand  Corporation,  2004). 


56 


Tactics  and  Operations  Group,  because  they  have  been  tasked  to  provide  standardized 
training  and  instructor  qualifications  for  the  Ground  Combat  Elements  (GCEs). 

The  designated  oversight  entity  should  then  hold  host  eonferenees  or  Integrated 
Proeess  Team  (IPT)  meetings  that  inelude  all  GCE  stakeholders  (battalion  and  eompany 
eommanders,  platoon  leaders,  communications  officers)  with  an  interest  in  company  and 
below  lERs.  Due  to  eurrent  Operational  Tempo  (OPTEMPO)  the  development  of  the 
lER  list  may  be  best  eompleted  by  students  at  the  resident  Command  and  Staff  (C&S) 
eourse  or  the  Expeditionary  Warfare  Sehool  (EWS).  The  IPT  or  resident  students,  with 
guidanee  from  the  USMC  “seientifie  body”  to  define  teehnieal  limits  of  what  is  possible 
and  also  means  to  optimize  bandwidth  as  diseussed  above,  should  develop  three 
eapability  sets  based  on  what  net-eentrie  means  (or  should  mean)  at  the  taetieal  level  and 
eombat  experienee  in  eurrent  asymmetrie  battlefield. 

Those  three  eapability  sets  should  fall  within  the  MCTOG  eoneept  of  “heavy,” 
“medium”  and  “light”  CEOCs,  to  address  the  information  exchange  requirements  for  a 
EOB  setting,  a  meehanized  or  mobile  foree,  and  a  foot  mobile  or  heli-bome  foree.  The 
list  should  be  standardized  enough  to  be  applieable  to  any  GCE  element  from  the 
company  and  below  but  also  allow  growth  room  for  personalized  operating  proeedures 
and  also  allow  for  the  introduction  of  new  teehnology  as  it  beeomes  available. 

The  infantry  eompany  is  just  one  element  of  the  MAGTF  that  requires  further 
researeh  into  the  lERs  for  small  unit  leaders.  In  order  to  optimize  the  eombined  arms 
effeets  that  MAGTE  organization  allows,  small  unit  leaders  aeross  the  eombat  elements 
will  need  support  in  making  deeisions  in  an  isolated  environment,  therefore  similar  lER 
lists  should  be  developed  for  those  elements. 

1.  Capability  Based  Acquisition  across  the  MAGTF 

Once  the  line  item  list  of  lERs  that  support  small  unit  deeision  makers  has  been 
developed  Marine  Corps  Systems  Command  (MCSC)  should  seek  out  applieations  or 
teehnieal  solutions  to  be  used  to  pass  those  exehanges  aeross  whatever  network  is 
established  in  the  AOR.  Again,  the  developers  of  these  applieations  should  keep  in  mind 
efforts  to  redefine  network  eentrie  and  optimize  bandwidth. 


57 


When  the  optimized  list  of  lERs  and  associated  applications  for  transmittal  are 
determined,  testing  can  be  done  to  determine  the  bandwidth  requirements  of  that 
particular  mix.  The  list  should  be  tested  for  bandwidth  requirements  during  actual 
training  scenarios  (i.e.,  Mojave  Viper  or  other  pre-deployment  training  opportunities). 
This  would  provide  validation  of  the  line  item  list,  help  determine  how  much  or  how  little 
training  is  required  to  successfully  operate  the  new  equipment,  and  how  much  or  how 
little  manpower  requirements  would  be  impacted. 

E,  THE  FINAL  WORD 

Within  days  of  finalizing  the  draft  of  this  thesis,  the  authors  received  a  draft 
version  of  the  most  recent  COC  Study  of  CAPESET  V  for  MAGTE  Command  and 
Control.24  This  report,  validated  by  MCCDC  C2ID,  develops  similar  recommendations 
and  notes  similar  shortfalls  in  defined  lERs  for  smaller  than  battalion  size  units.  It  is  very 
comprehensive  in  its  analysis  of  the  issues  this  thesis  addresses  and  should  be  referenced 
for  those  who  intend  to  continue  the  research  started  in  this  thesis. 


24  MCCDC,  C2ID,  Combat  Operations  Center  (COC)  Study  Capability  Set  (CAPSET)  V for  Marine 
Corps  Air-Ground  Task  Force  (MAGTF)  Command  and  Control  (C2),  ver.  1.9.  (Quantico,  VA:  U.S. 
Marine  Corps,  2008). 
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APPENDIX  A.  SWE-DISH  IPX  TECHNICAL  SPECIFICATIONS 


The  following  tables  are  eopied  directly  from  the  Swe-Dish  Instructions  for  Use: 
IPT-i  Mil  Suitcase  2,4  Satellite  Communications  Terminal  featuring  iPirect  rev.  3.3, 
March  2007. 


RF  Characteristics 

Ku  band 

General  RF 

Antenna  concept 

Gregorian  type  dual  optics  antenna  at  Ku  band.  Eiiipti- 
cai  4-piece  main  reflector  with  size  0.90  x  0.66  m.  and 
folding  feed  atm.  Carbon  reinforced  plastic  (CRP)  con¬ 
struction. 

Antenna  model  designation 

SWE-DISH  90-66K  EDS 

Sidelobe  performance 

29  -  25  Log  6  dBi  in  azimuth 

Receive  Performance 

Frequency 

10.95-  12.75  GHz 

Gain  at  midband 

38.3  dBi 

G/T  at  58  K  (0.8  dB)  LNB,  20“ 
el,  20“  C,  clear  sky 

19.3  dB/K 

Transmit  Performance 

Frequency 

13.75  -  14.50  GHz  (Extended  Ku) 

Gain  at  midband 

38.4  dBi 

Polarization  Performance 

Polarization 

Linear 

Cross-polar  discrimination 
within  1  dB  cone 

>30  dB 

EIRP  Capability 

EIRP 

53  dBW  @  P  -1  dB 

Table  4.  IPT  RF  Characteristics 
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General  Characteristics 

Ku  band 

General 

PC  platform 

The  Suitcase  has  an  embedded  Linux  PC  piatform  with 
network  connection. 

Monitoring  and  Control 

The  Suitcase  is  controiled  via  graphicai  web  interface 
and  an  embedded  http  server. 

Data  inputs  and  processing 

Network  connections 

TCP/IP  LAN  interconnectivity  10/100  base  T  on  a 
MIL-C-26482  series  1  connector. 

iP  Routing 

Transmission  modes 

Bi-directional  (duplex)  and  uni-directional  (simplex) 
operation  supported 

Video  streaming 

Supports  transmission  of  live  video  stream  over  IP 

Modulation  iDirect 

Transmit  mode 

Network  TDMA 

Modulation  type 

QPSK 

Date  rate,  maximum 

4200  kbps 

Code  types 

TPC 

Antenna  travel 

Antenna  alignment 

Built  in  GPS,  electronic  compass  and  inclinometer. 

Positioning 

Motorized 

Azimuth  range 

±  30°,  0.1°  step  size 

Eievation  range 

5°  -  90°,  0.1°  step  size 

Polarization  range,  linear 

186°,  0.1°  step  size 

Platform  levelling 

Pitch  and  roll 

Built-in  compensation  for  pitch  and  roll  due  to  using 
platform  independent  reference  to  true  vertical/horizon¬ 
tal. 

Environmental  Performance 

Ambient  temperature 

Operational  -20°  C  to  +40°  C,  internal  heater/cooler 

Mil  version  -20°  C  to  +50°  C 

Storage  -40°  to  +70°  C 

Solar  radiation 

Operational  in  up  to  1100  W/m^ 

Wind  speed 

Operational  up  to  20  m/s,  anchored  unit  (Eutelsat  type 
approval) 

Humidity 

Operational:  95%  non-condensing 
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General  Characteristics 

Ku  band 

Rainfall 

Maximum  100  mm/h  excluding  link  budget  effects 

Sealing,  including  PSU 

IP65 

Altitude 

Operational  up  to  3  000  m,  survival  up  to  12  000  m  alti¬ 
tude 

Mechanical 

Weight 

Approximately  39  kg  depending  on  options 

Dimensions 

70  X  47  X  31  cm  stowed  for  transportation 

Electrical 

Mains  supply 

External  dedicated  power  supply  unit  (PSU)  accepting 
AC  or  DC  input: 

AC  supply:  100  -  240  V  AC,  50  -  400  Hz,  900  W 

DC  supply:  21  -  32  V  DC,  39  -  26  A 

Total  power  consumption 
(Suitcase) 

700  W 

Table  5.  IPX  General  Charaeteristies 


PSU  Parameters 

Value 

Operating  temperature 

-30’  to  +  SO’C 

Rain 

100  mm/h 

Humidity 

95%  condensing 

Sealing 

IP65 

Altitude  operational 

5.000  meters 

Altitude  non  operational 

13,600  meters 

Low  air  pressure 

150  mbar 

Pressure  change 

100  mbar/min 

Dimensions 

38x14x18  cm 

Weight 

4.5  kg 

Table  6.  Power  Supply  Unit  Parameter 
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BUC  Parameter 

Value 

Input  Frequency 

950  -  1700  MHz 

Output  Frequency 

13.75-  14.50  GHz 

Local  Oscillator  Frequency 

12.80  GHz 

Local  Oscillator 

3  dBm  ±  7 

Reference  Frequency 

10  MHz 

Power  Requirements 

+  10.5  to  +18.0  VDC 

Table  7.  Block  Up  Converter  Parameters 


Modem  Parameter 

Value 

Type 

Network  TDMA  modem  (L  band) 

Operating  frequency 

950  -  1700  MHz 

Maximum  transfer  rate 

4200  kbps 

Power  requirements 

20.5-27.5  VDC 

Table  8.  Internal  i-Direct  Modem  Parameters 


SSPA  Parameter 

Value 

Operating  Frequency 

13.75-  14.50  GHz 

Saturated  Power  Output 
(nominal) 

35  W 

Power  Requirements 

+  10.5  to +13  VDC 

Table  9.  Solid  State  Power  Amplifier  Parameters 
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LNB  Parameter 


Value 


Input  Frequency 

10.95-  11.70  GHz 

11.70-  12.20  GHz 

11.25-  12.75  GHz 

Output  Frequency 

950-  1700  MHz 

Conversion  Gain  (25*^) 

55  -  60  dB  typical 

Noise  Figure  (25°) 

0.8  dB  typical 

Power  Requirements 

+15  to  +24  VDC 

Table  10.  Low  Noise  Bloek  Down  converter  Parameters 
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APPENDIX  B.  IX  CHARIOT^  TECHNICAL  SPECIFICATIONS 


The  following  description  and  figure  of  the  IX  Chariot®  software  and  its  processes 
is  taken  directly  from  the  IXIA  manual  Getting  Started  with  IX  Chariot®,  release  6.50, 
2006. 

A,  ABOUT  IX  CHARIOT® 

“IxChariot  provides  thorough  performance  assessment  and  device  testing  by 
emulating  hundreds  of  protocols  and  applications  across  thousands  of  network  endpoints. 
Available  with  both  node-locked  and  floating  license  support,  IxChariot  provides  the 
ability  to  confidently  predict  the  expected  performance  characteristics  of  any  application 
running  on  wired  and  wireless  networks.  Using  application  scripts  that  emulate 
application  data  flows,  IxChariot  can  help  you: 

•  Test  the  performance  and  capacity  of  network  hardware  and  software. 

•  Compare  competing  network  products  before  purchase. 

•  Identify  the  source  of  performance  problems. 

•  Predict  the  effects  of  running  new  applications. 

•  Measure  and  baseline  typical  network  operations. 

•  Verify  the  performance  you  are  expecting  from  network  service  providers.” 

B,  BASIC  SETUP 

The  application  consists  of  a  Console  Program  and  distributed  Performance 
Endpoints.  The  Console  stores  all  test  files  and  scripts  as  well  as  collects  all  performance 
statistics  sent  from  the  Performance  Endpoints  via  polling.  Polling  rate  can  be  set  by  the 
user.  Endpoints  use  the  Application  Scripts  to  create  the  same  data  flows  an  application 
would  send  between  computers,  without  having  to  install  the  actual  application.  Each 
Application  Script  can  also  be  altered  by  the  user  to  reflect  a  specific  application,  if  no 
such  definition  exists  in  the  Console’s  library  of  scripts.  Eigure  4  shows  the  basic  setup 
of  IX  Chariot®  . 
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Endpoint  1 


Figure  4.  IX  Chariot®  Basic  Setup 


Endpoint  2 
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